Multi-level approval workflows: sequential, parallel and conditional routing explained
This page covers how the three routing types behave, how to design an approval chain that survives a reorganisation, and what happens in the cases most implementations get wrong — an approver on leave, a rejection at the final stage, a request edited after it was partly approved.
Why an approval process gains levels
A single-stage approval answers one question: does the person with authority agree? A multi-level approval exists because that question splits into several that different people are positioned to answer. A line manager knows whether the request is real and whether the team needs it. Finance knows whether the money exists and which budget it lands against. A department head knows whether it fits the plan for the quarter.
Levels are added for one of three reasons: authority, where the amount or risk exceeds what one approver can sign for; context, where no single person can assess every dimension of the request; and separation of duties, where the person who benefits from a decision must not be the person who authorises it.
The design question is never how many levels a process could have. It is which question each level answers, and what happens when the person who answers it is unavailable.
Chain, stage, level, matrix
The vocabulary in this area is used loosely across platforms, which makes documentation hard to compare. We use it as follows on this page.
Approval chain
The full ordered set of stages a given request must pass through, from submission to final outcome.
Glossary: approval chainApproval workflow
The wider process a chain sits inside — the trigger that starts it, the stages, and the outcome recorded at the end.
Glossary: approval workflowStage, or level
One decision point in the chain, with its own approver or approver group and its own clearing condition.
Glossary: multi-level approvalApproval routing
The logic that decides which approver receives a request at each stage, and in which order the stages run.
Glossary: approval routingMulti-stage approval
Used interchangeably with multi-level approval. Some platforms reserve "stage" for a group of parallel approvals inside one level.
Approval matrix
The reference table that maps request attributes — amount band, department, category — to the chain that should apply. Covered in the design section below.
Three ways to route a multi-level approval
Almost every approval chain in use is built from these three patterns, alone or in combination. The choice determines how long the chain takes, how it behaves when someone is unavailable, and how much of it has to be redesigned when the organisation changes.
Sequential
Stages run in a fixed order. Each stage begins only once the previous one has cleared. Total time is the sum of every stage.
Parallel
Approvers are notified at the same time. The stage clears on a rule you define: all of them, any one, or a quorum.
Conditional
The chain is selected at runtime from the request's own data — amount, department, category, requester role.
How sequential approval routing works
In a sequential chain, each stage is gated on the one before it. The second approver is not notified — and in most designs cannot see the request — until the first has approved. This is the default in most approval tools because it mirrors how authority is usually delegated: upward, one step at a time. Glossary: sequential approval
Line manager confirms the request is legitimate
The requester's manager is resolved from the directory at run time. They confirm the request is real, needed, and within the team's remit. On approval, the request advances and the next approver is notified. On rejection, the chain stops here and the later approvers never see it.
Finance checks budget and coding
Finance sees the request only after manager approval, which means they are never asked to review something the manager would have rejected. They confirm the budget exists, the cost centre is correct, and the amount matches any quote attached.
Department head gives final authorisation
The final stage authorises the spend against the departmental plan. Because the two earlier stages have already cleared, this approver reviews a request that has been validated for legitimacy and for budget, and is deciding only on priority.
How parallel approval routing works
In a parallel stage, every approver is notified at the same time and can respond in any order. Elapsed time is set by the slowest responder rather than the sum of all of them, which is why parallel stages are used wherever the approvals are genuinely independent of each other. Glossary: parallel approval
The decision that defines a parallel stage is its clearing rule. Before building one, answer this: does the stage need all approvers, any one approver, or a quorum?
Unanimous
Every approver in the stage must approve. Any single rejection fails the stage. Use it where each approver owns a distinct veto — legal, security, data protection. The trade-off is that one unavailable approver blocks the stage entirely, so timeouts and delegates are mandatory rather than optional.
First responder
The stage clears as soon as one approver approves, and the request is withdrawn from the others. Use it where approvers are interchangeable — a duty rota, a pool of shift supervisors. The trade-off is that a single approver decides, so the stage carries no more assurance than a single-approver stage.
N of M
The stage clears once a set number of approvals arrives — any two of three, three of five. Use it where a group holds authority collectively and full attendance is unrealistic. Decide in advance whether rejections also count toward a threshold, and what happens if the group deadlocks.
Parallel stages compose with sequential ones, and most real chains mix them. A common shape is a sequential chain whose final stage is parallel: manager, then finance, then any two of three budget holders. The chain preserves escalating authority while keeping the final stage from depending on one person's calendar.
How conditional approval routing works
Conditional routing selects the chain at run time from the request's own data. Rather than one chain that every request follows, the process holds a set of chains and a rule that decides which one applies. The rule is normally evaluated on submission, though some designs re-evaluate it if the request is edited mid-flight. Glossary: conditional approval
Attributes chains are commonly routed on
Amount
Bands map to depth. Small requests clear at one level; larger ones add finance, then an executive stage.
Department
Different departments carry different chains, cost centres and thresholds for an otherwise identical request.
Category
Request type pulls in the reviewer who owns it — software adds security review, contractors add legal.
Requester role
Seniority can shorten a chain, and separation of duties can lengthen it when the requester sits in the approving group.
A worked threshold table
Conditional rules are easiest to review as a table. This is a purchase-request example, written the way an approval matrix normally is — one row per band, one column per level.
| Amount band | Level 1 | Level 2 | Level 3 |
|---|---|---|---|
| Under 1,000 | Line manager | — | — |
| 1,000 – 10,000 | Line manager | Finance | — |
| 10,000 – 50,000 | Line manager | Finance | Department head |
| Above 50,000 | Line manager | Finance | Any 2 of 3 budget holders |
Two details in that table matter more than they look. The bands must be contiguous and closed — a request for exactly 10,000 has to land in one row and only one row, and a gap between bands is a request with no chain. And the final band changes routing type as well as depth, moving from a single approver to a quorum. Conditional routing that only changes depth is the simpler half of the pattern.
Designing the approval chain
Most approval chains are inherited rather than designed. They accumulate levels after incidents, keep them after reorganisations, and are documented in a spreadsheet that stopped matching the configuration some time ago. Three decisions do most of the work.
Threshold design
Thresholds decide how much of the organisation a request has to cross. Set them too high and small requests consume executive attention; too low and the chain becomes a formality that approvers clear without reading. The most common failure is having too many thresholds rather than badly placed ones — each additional band multiplies the number of routing paths that have to be tested and maintained. Three or four bands covers most processes.
Role-based rather than named approvers
A chain that names people breaks on the first reorganisation, and it usually breaks silently — requests continue routing to someone who has changed team, or to an account that has been suspended. A chain that resolves roles from the directory at run time survives the change, because the question it asks is "who is the requester's manager now" rather than "who was it when this was built". Named approvers are appropriate where the authority genuinely attaches to the individual rather than the post, which is rarer than most configurations assume.
The approval matrix as a design tool
An approval matrix is the reference table mapping request attributes to the chain that applies — the threshold table above is one. Its value is as a review artefact: it is the form in which non-technical stakeholders can check the rules, and the form in which an auditor can ask why a particular request took the path it did. Keep it generated from, or checked against, the live configuration. A matrix that has drifted from the running process is worse than none, because it is trusted.
The five cases that break multi-level approvals
The happy path is the easy part. These five cases are where implementations diverge, and they are the ones worth deciding explicitly before anything is configured.
The approver is unavailable
Configure a delegate, a timeout, and an escalation target for every stage. A delegate holds standing authority to act for an approver during an absence, recorded as acting on their behalf. A timeout defines how long the stage waits before it does something else. Escalation defines what that something is — usually the approver's own manager. Decide whether a timeout escalates, auto-approves, or auto-rejects; auto-approval is convenient and quietly removes the control the stage existed to provide.
The request is rejected mid-chain
Pick one of three behaviours and apply it consistently: return to requester, return to the previous approver, or restart the chain. Returning to the requester suits rejections caused by a fixable defect — a missing quote, a wrong cost centre. Returning to the previous approver suits chains where that approver can resolve the objection themselves. Restarting is the strictest and the slowest, and it is the right choice where an earlier approval was given on the basis of something now known to be wrong.
The request is edited after partial approval
Define which fields are material, and invalidate prior approvals when one of them changes. If the amount is edited upward after the manager approved, that approval no longer covers what is being requested — and if the edit crosses a threshold, the chain itself has changed. Immaterial edits, such as a corrected description, should not reset anything. Without this rule, a request can be approved at one value and executed at another.
The requester appears in their own chain
Detect the collision at routing time and substitute the next authority up. This happens routinely to managers who submit requests that route to managers, and to anyone covering a vacant post. Removing the stage entirely is the wrong fix, because it silently reduces the number of approvals. The same rule should catch delegation loops, where an approver's delegate is the requester.
Someone asks what happened, six months later
Log every stage with actor, timestamp, decision, the request state at the time of that decision, and the rule that selected the chain. The last two are the ones usually missing. Without the request state, an audit cannot tell what an approver actually agreed to; without the routing rule, it cannot tell whether the request took the path it should have. Delegated actions need both parties recorded, and timeouts need to be logged as events rather than silently passed over.
Where hand-built approval logic runs out of road
Most multi-level approvals start as something small and reasonable: a form, a script, a sheet that tracks who has signed. The pattern holds until the chain acquires a second condition.
Teams graduating from brittle scripts usually recognise all three of these. None of them announce themselves — each one surfaces as a request that quietly stopped moving.
State lives in a spreadsheet
The approval's current stage is a cell someone updates. Two approvers acting at once overwrite each other, a sort reorders the rows, and there is no record of what the state was before the last edit.
Failures are silent
A trigger misses, a quota is hit, an API call fails. Nothing retries and nobody is told, so the request simply stops. It surfaces when the requester follows up, which is usually well after the decision was needed.
One person understands it
The routing rules exist in code that one person wrote, with the thresholds hard-coded. Changing a band means editing a script, and reviewing the rules means reading it. When that person moves on, the process becomes untouchable.
Multi-level approvals in Google Workspace
Approval chains are most reliable when they run where the work already happens. For teams on Google Workspace, that means the request arrives from a Google Form or a Drive file, the approver responds in Gmail or Google Chat, the approval matrix is reviewable in Sheets, and role resolution reads from the Google Directory — so a chain that routes to "the requester's manager" stays correct as the directory changes.
We build Zenphi natively for Google Workspace, which is why role resolution, delegation and audit logging draw on Workspace as the source of truth rather than a copy of it. Where a chain needs a judgement that rules cannot express — reading an attached quote, classifying a free-text request — Zenphi lets teams choose AI agents across three providers: Gemini, OpenAI, and Claude.
Directory
Manager, department and group membership resolved at run time for role-based routing.
Forms & Drive
Requests enter from a form submission or a document, with attachments carried through the chain.
Gmail & Chat
Approvers act where they already work, with the request state shown in the message.
Sheets
The approval matrix stays reviewable by the people who own the thresholds.
Multi-level approvals by use case
The routing patterns above are the same everywhere. What changes is the data the conditions read and who sits at each level.
Invoice approval workflow
Invoices route on amount, vendor and cost centre, usually with a three-way match before the finance stage. Exception handling matters more here than depth.
Read more →Purchase order approval workflow
Purchase orders are the classic threshold case, with bands mapping directly to approval depth. Delegation is critical because procurement cannot wait on one calendar.
Read more →Expense approval workflow
Expense chains are shallow but high volume, so the design pressure is on policy checks and auto-approval rules rather than levels.
Read more →Document approval workflow
Documents add version control to the chain, since an approval attaches to a specific revision. Parallel review is common before a sequential sign-off.
Read more →Content approval workflow
Content review is usually parallel first — legal, brand, subject expert — then a single sequential publish approval. Round-trip revisions are the norm rather than the exception.
Read more →Google Forms approval workflow
A form submission is the most common entry point for a multi-level chain. The form fields become the data the conditional rules read.
Read more →Multi-level approval workflows — common questions
Map your approval chain before you build it
If you are designing a multi-level chain on Google Workspace, the routing types, thresholds and edge cases above are the decisions worth settling first. Our docs cover how each maps to a Zenphi flow, and the community is a good place to compare notes with teams running similar chains.