Define the request states, permitted transitions and responsible roles before building an approval screen. Automation cannot resolve a contradictory policy. It should make each decision traceable, including when a reviewer is absent, the request changes or an external system fails.
Describe the complete request lifecycle
Consider an illustrative purchase request: draft, submitted, under review, approved, rejected or cancelled. Every transition needs an authorized actor and a condition. Creating a request does not necessarily authorize approving it. A department manager may only act within that department, not across the company.
Agree what an edit does to an existing approval. A changed amount might require a new review; changing the supplier might also invalidate the decision. Keep the approved version of the request linked to the decision. A green approval badge detached from the content it approved is not reliable evidence.
Decide the exceptions before implementation
| Situation | Policy decision | Acceptance evidence |
|---|---|---|
| Requester is also department manager | Identify an alternate reviewer | Self-approval is denied where prohibited |
| Reviewer is absent | Bound delegation by scope and time | Delegator and acting reviewer are recorded |
| Approved amount changes | Re-review or reject the edit | Old approval cannot silently authorize new terms |
| Two reviewers act together | Allow one valid transition | Financial effects occur once |
| ERP integration fails | Show a recoverable waiting state | No false completion message |
These are questions for the business owner, not a universal purchasing policy. Use sanitized examples at the actual approval thresholds. Include the exact boundary value, not only an amount far below and far above it. Record who resolves disputed rules before they become implementation assumptions.
Enforce the decision on the server
Hiding a button is not access control. Each request must verify the user, organization, resource and current state. Test a direct URL, a replayed request after the state changes, and a user from another organization. Rejection logs should support investigation without copying confidential documents into application logs.
An external effect such as creating a purchase order needs duplicate protection at the integration boundary as well as the screen. Define a stable operation identity, retry behavior and reconciliation process. A reviewer should be able to see the last attempt and next permitted action rather than pressing approve repeatedly to find out what happened.
Plan how the workflow will be operated
Name the person who changes the policy, reviews permissions and withdraws expired delegations. Provide a queue of requests needing attention. Do not promise a fixed approval time without knowing the review workload and staffing arrangements.
Run a complete representative cycle before expanding the rollout: submission, review, an edit, rejection, resubmission and the external handoff. Have the business owner inspect both the final record and its history. A technically valid workflow can still encode the wrong business decision.
Bring these decisions to a custom business systems project. Review systems integration boundaries and the project brief checklist before requesting a quotation.
Sources and editorial status
- OWASP Authorization Cheat Sheet.
- Original contribution: the exception matrix and purchase-request acceptance example; not a completed client implementation.
