How to map an approval process
How to map an approval process so the map is worth opening: where the authority limit sits, what a refusal actually does to the request, and who decides when the approver is away.
Mapping an approval process means drawing the four things a chain of names omits: the condition that decides who approves, who decides when that person is away, where a refusal goes, and what it records.
The short version
- Approval chains are the stable part; map the conditions that change them.
- A refusal the submitter can fix needs its own row; only the final ones may share an ending.
- State whether a threshold reads the whole request or one line, and what happens exactly at the limit.
- Every gate needs a named deputy, or the map has a queue where it claims to have a decision.
- An approval nobody can tie to a person and a version is a timestamp, not a control.
An approval map is mostly a map of refusals
An approval process is not the chain of names it is usually drawn as. The chain is the least interesting part of it: it is stable, most people already know it, and it is the one thing they do not need a diagram for. What a map has to establish is the conditions under which that chain changes: the value at which a second signature appears, the case that leaves the process without ever being approved, and who acts when the named approver does not.
That a refusal has to route somewhere is settled. What a map adds is the row number it routes to, and the four refusals in the example do not agree: two of them go back into the process ("Returned" to the claimant's own submission row, "Breach" sideways to "Exceptional approval granted?"), while "Refused" and "Rejected" both end at "Claim rejected and closed". A shared ending is defensible only where nothing the submitter does would change it, which is the test to apply before merging two exits.
The example below is an expense claim, chosen because its authority limit is explicit and its exception routes are the bulk of the diagram rather than a footnote. Watch "Receipt attached and within policy?" resolve three ways, one of them straight back to the claimant, and watch the Auditor lane at the end of the Assurance phase, where sampled claims are tested against the evidence that was supposed to justify them.
Receipt to reimbursement or refusal
Four routes out of this expense claim are refusals, and watching where each of them lands is what separates a correction from a closed claim.
Start where the evidence does
The chart opens on a state of the world rather than a task somebody performs: "Expense incurred and receipt captured": the receipt exists before any approval question can be put to it. The row after it is the last thing the claimant controls; everything past that is other people deciding.
Two refusals, one shared ending
Each of the three diamonds here can refuse. "Receipt attached and within policy?" sends "Returned" backwards to the row the claimant controls and "Breach" sideways for an exception, while "Refused" and "Rejected" both arrive at "Claim rejected and closed": the one ending two refusals may share.
The limit decides who signs
"Value over approval threshold?" sends the claim through "Escalate to second approver" and then rejoins the flow at "Duplicate claim detected?". The limit changes how many approvals a claim collects, not which route it takes, and the independent finance checks apply either way.
Approvals are tested afterwards
The two labelled arrows out of "Post claim to expense ledger" are not alternatives: "Reimburse" takes every claim on towards payment, while "Sampled" also draws some of them into the Auditor lane, where "Claim supported by evidence?" can still reach "Recover amount and log finding".
How it works
Write the authority limits down first
Before any boxes exist, copy each value band out of the delegation schedule and write beside it the two things the schedule almost never states: what the amount is measured on (claim total, single line, monthly total) and which side of the number the boundary falls. Otherwise approvers settle both privately, differently each time.
Decide what each refusal does
For every point that can say no, write which outcome it produces: back to the submitter for correction, sideways to somebody with the authority to permit an exception, or closed. The correction case needs the number of the step the submitter genuinely repeats, because that backwards arrow is what makes the map honest.
Type the steps and number the arrows
In QueryChart the sheet is the diagram: one row per step, its wording in Box text, and in Line to the row number it hands the request to, several numbers, comma separated, where it can go more than one way. No box is placed by hand, which is why the map survives being corrected in a meeting.
Turn the limits into labelled decisions
Any row that tests something is a Decision, set in the Shape column, worded as the question its owner is really answering. The branch labels go into Line text, positioned to match the numbers beside them: "Over limit" and "Within limit" on the threshold row is how a reader places their own request.
Lane each step by who is accountable
The Vertical lane column holds the role (Employee, Line manager, Finance / AP, Payroll, Auditor) and the phase goes into the Horizontal lane. Word those phases as states a submitter can be told, because Validation and Finance review answer where a claim has got to, and a request whose phase nobody can name is the one chased by email.
Walk it as the submitter, then name the deputies
Read the map from the requester's side: at each diamond, say what they are told and what they do next, and fix every point where the answer is nothing. Then put a deputy on every gate (a name, not a role) and have the same names entered on the delegation schedule, because a map and a schedule that disagree are worse than neither.
Mistakes to avoid
Hiding three acts in one box
One box labelled approval hides three separate acts: checking the request is complete, authorising the money, and verifying afterwards that it was justified. They have different owners, and only the middle one is a decision.
Thresholds with no boundary
Writing over £500 without saying what happens at exactly £500 leaves the routing to whoever is reading it. One claim at the limit collects a second signature and the next does not, and neither approver has done anything wrong.
No deputy anywhere on the map
Every gate is a queue while its owner is on leave. A map that names one approver and no delegate is describing a process that stops for a fortnight each August and calls the delay a control.
Leaving sampling off the diagram
Where nothing approved is ever re-examined, the approvals are untested and the map cannot show what the control is worth. Draw the sample, the rule that selects it, and what a finding sets in motion.
Map your own approval process
Open the expense claim example and make it yours: your own limits, your own deputies, and a route out of every refusal.
Related guides
Frequently asked questions
What should an approval process map show?
Four things a chain of approver names does not: the condition that decides who approves this particular request, who decides it when that person is on leave, the route out of every refusal, and where the decision is recorded. A map that shows only the sequence answers a question nobody had. The test is to take a real request that went wrong, trace it on the diagram, and see whether the diagram explains what happened to it.
What happens if an approver does not respond?
Whatever the process says, and most processes say nothing, so the request simply waits. The three honest options are a reminder that repeats, a named delegate who can decide in the owner's absence, and escalation to the level above after a stated period. Auto-approval on a timeout is the fourth option and it is not one: silence is not a decision, and what it writes to the record cannot be told apart from a considered approval. Draw the delegate on the map, because the absence is routine, not exceptional.
What is the difference between rejecting and returning a request?
Returning means the request is incomplete or incorrectly prepared and the submitter can fix it: a missing receipt, the wrong cost centre, an unsigned form. Rejecting means the request as intended is not permitted, and no amount of resubmission changes that. Conflating them produces the familiar loop where somebody resubmits a policy breach three times with better paperwork. On a map they are different arrows, and the returned one points backwards.
Does an approval threshold apply to the total or each line?
To whichever unit the policy states, and most policies state neither, which is how £600 of hotel nights becomes one claim needing a second signature or five claims needing none. Fix the unit, then fix the boundary: is a request at exactly £500 over the limit or within it? Put both on the decision row, in the currency the request is submitted in, because the alternative is every approver settling it for themselves in the moment.