The approval chain: how work keeps flowing without depending on one person

In the previous two lessons you documented each process on a single page, then decided who executes and who approves at each step. What's left is the step that makes both work: connecting the steps into one path that moves on its own, without stalling when someone is away and without choking on a single person who approves everything. That path is the approval chain, the last thing you prepare before considering any system.

What an approval chain is

An approval chain is an agreed ordering of the steps a request passes through until it becomes a binding decision. At each step sits a gate with three properties: who opens it, on what condition, and where the request goes if accepted or rejected. Without this written ordering, every request travels differently depending on who received it, and each transaction gets its own history.

Sequential or parallel

The first design decision: do the steps run one after another, or together?

• Sequential: each step waits for the one before it. Clearer and easier to trace, but slower, because one delayed step halts everything after it.
• Parallel: two independent steps run at once, like a finance review and a quality review of the same request. Faster, but it needs a join point that waits for both branches before the request continues.

The practical rule: don't make one step wait for another unless it genuinely depends on the earlier result. Run unrelated steps together to save time without losing control.

Conditional routing: not all requests are equal

A common mistake is sending every request down the same long path, so management's time drains on tiny approvals while a large request gets no more care than a trivial one. The fix is to branch by a clear condition, most commonly the amount. Take an expense approval:

The numbers are illustrative; set your own limits by your business. The size of the decision sets the length of its chain, so small requests aren't held up by large ones, and large ones aren't rushed like small ones.

A time limit per step, and escalation on delay

A chain with no time limit per step dies at the first busy approver. Give every gate a deadline, and define what happens when it lapses: does the request escalate to the level above, or to the approver's backup at the same level? For example, a request stuck at the finance manager for two days escalates to the CEO on the third day automatically. Escalation isn't a punishment; it's a valve that keeps work from halting because one person is busy. Write the deadline and the destination together, since a deadline without a destination just means a request suspended with no end.

Make the chain independent of people

Here is where last lesson pays off. Tie every gate to a role, not a name: the finance manager approves, not a specific person. When the role-holder is away, their pre-defined backup takes over and the chain moves without asking after any individual. The most dangerous point in any chain is a gate opened by one person with no backup, because it turns their absence into a full stop. Review your chain, find every such gate, and define a backup before you need one.

In a good chain, the request always knows its next destination, whether the role-holder is present or away. If it has to ask a human where to go, the chain is incomplete.

A checklist before you adopt your chain

• Every request has one clear starting point that triggers the chain.
• You've identified which steps are sequential by necessity and which run in parallel.
• The path branches on a clear condition like amount, so the small doesn't travel the large one's route.
• Every step has a time limit and an escalation destination when it lapses.
• Every gate is tied to a role, not a name, and every role has a defined backup.
• No gate is opened by a single person with no backup.
• Every request leaves a written trace: where it is now, who delayed it, and when.