Who this is for: Process owners designing purchasing, discount, access, or document approvals.
An approval workflow needs more than an Approve button. It needs to know who may decide, which version they are approving, and what happens when that person is absent or the request changes.
Use the matrix below to define those rules. It describes a synthetic purchasing request; the thresholds and authorized roles must come from your own policy.
Separate request state from notification delivery
A message being delivered doesn't mean the request was approved. Store a durable request identifier, version, current state, and decision history. The notification should link to that record.
Represent pending, approved, rejected, withdrawn, and expired states explicitly where the process uses them. Define the permitted transitions. A timed-out request should not silently become approved.
- Step 1
Submitted
Validate required evidence and assign a request version.
- Step 2
Pending
Route to an authorized approver or delegate.
- Step 3
Decided
Record actor, time, decision, and approved version.
- Step 4
Executed
Perform the authorized action once.
- Step 5
Changed
Apply the reapproval rule before further action.
Write the routing matrix and the exception route
Use amount, department, request type, or risk classification only when policy makes them relevant. State whether several approvals are sequential or concurrent, and whether one rejection ends the request.
Make the fallback explicit. If the approver is unavailable, route to an authorized delegate; don't select an arbitrary manager. If no authorized delegate exists, leave the request pending and escalate to the policy owner.
| Condition | Route | Exception behavior |
|---|---|---|
| Standard request within delegated authority | Authorized budget owner | Absent owner → registered delegate |
| Request outside delegated authority | Additional authorized approval | No authority → policy owner |
| Requester is also approver | Independent authorized approver | No self-approval by default in this example |
| Required evidence missing | Return for correction | No execution |
| Material change after approval | New request version; reapproval | Prior decision cannot authorize new version |
Protect the decision against replay and stale actions
An approval link may be clicked twice or opened after the request has changed. Verify the actor's current authorization, the request version, and the current state before accepting the action.
Record the actor, decision, timestamp, reason where required, and evidence references. Perform the downstream action once using the request's persistent identifier. If the action times out, reconcile the destination before trying again.
- A second click cannot execute the request twice.
- An old link cannot approve a changed request.
- A withdrawn request cannot be executed.
- A departed or unauthorized approver cannot decide.
- The destination outcome is linked to the request.
Test absence, delay, and disagreement
Run cases for approver absence, missing evidence, rejection, changed requests, and a timeout after execution. Ask the operator to resolve a pending request using the documented escalation route.
Set reminder and expiry timing from business needs. A reminder should not reset an overdue request's age or count as an approval. Measure unresolved requests by age and owner so the team can see a queue that is falling behind.
Free download · No email required
Approval matrix and exception test sheet
Use your organization's actual authority policy. Example routes are illustrative. Record request versions and test stale links, duplicate decisions, and absent approvers.
Open the CSV in Excel, Google Sheets, or another spreadsheet tool. The Markdown brief is editable in a text editor.
Common questions
- Should approval expire automatically?
- Only when the process defines what expiry means and who handles it. Expired approval should not imply permission to execute. Make renewal or reapproval behavior explicit.
