Setup Considerations: approval chain design

What this achieves

An approval chain decides who is asked, in what order, and what happens when nobody answers. Designing it before you draw it matters because a badly shaped chain stalls real work, and unpicking one while requests are already running is the expensive part.

Decision 1: how many steps

Every step is a delay. Two approvers means two waits, and the request moves at the speed of the slower one.

Start from the question “who would be accountable if this turned out to be wrong?” and give a step to each answer. Nobody who would merely like to know needs an approval step — they need a notification.

Example: a training request at HC Corp under an agreed cost genuinely needs one decision, from the requester’s manager. Adding a second step for Finance on every request adds a wait to hundreds of small requests to catch the few large ones. A condition that routes only the expensive ones to Finance does the same job without the delay.

Decision 2: who each step asks

An approval step names its approver in one of several ways, and they are not equally durable.

Option	Description
Manager of Requester	Resolved when the request runs. It survives reorganisations, new hires, and leavers without any edit to the route. This is the default for a reason.
Specific User	A named person. Precise, and fragile — the route needs editing when that person changes job or leaves.
By Job Title	Recorded on the step, but not yet resolved to a person when a request runs. Do not build a step your business depends on around it today.
By Role / Group	Recorded on the step, and subject to the same limitation as job title.

Example: HC Corp routes expenditure above an agreed threshold to Daniel Okonkwo by name. When he is promoted or leaves, that step has to be edited or every request above the threshold stops. Routing to the requester’s manager instead would not have needed touching.

Give any step that names a person a fallback approver as well, so a step whose approver cannot be resolved has somewhere to go.

Decision 3: sequential or parallel

Steps in a line run one after another. A parallel branch asks several people at once, and you choose what finishing means.

Option	Description
Sequential	Later approvers see earlier decisions. Slower, and appropriate where each approval builds on the last.
Parallel, all must approve	Everyone is asked at once and every answer is needed. A rejection ends the branch immediately rather than leaving the others waiting.
Parallel, any one approves	Everyone is asked at once and the first approval settles it. The remaining tasks are cancelled rather than left in inboxes.

Example: HC Corp asks Finance and the People team in parallel on a promotion, because neither decision depends on the other. Asking them one after another would add a day for no benefit.

Any-one-approves is the right shape for cover — three people who can each authorise, of whom one is usually available. It is the wrong shape for accountability, because it does not tell you who was meant to decide.

Decision 4: deadlines you would actually enforce

Each step can carry a time limit, a reminder before it, and an escalation target for when it passes. The limit is only useful if the escalation is one you would accept.

A deadline with no escalation target flags a task as breached and leaves it exactly where it was.
Escalating to the approver’s manager works where a manager exists above every approver on that step.
Escalating to a named person concentrates every breach on one inbox. Check that person agrees.

Example: 48 hours on a manager approval at HC Corp is realistic. Four hours is not, and a chain full of instantly-breached steps trains everyone to ignore the breach flag.

Decision 5: what you are willing to let through without a human

An auto-approval step passes a request when the rules you set match. Decide what happens when they do not: notify and route it to a person, skip the step, or stop the request. Skipping is the one to be careful with — a skipped approval is an approval that never happened, and it will not look like a gap on the record.

Example: HC Corp auto-approves requests from employees at or above a senior grade and routes everything else to a manager. The saving is real, and the exceptions are still seen by a person.

Decision 6: separation of duties is not optional

The person who raises a request can never approve it. An approval step cannot be pointed back at the requester, and an approver who turns out to be the requester is blocked and the task escalated.

Design around that rather than into it. A chain whose only approver is the same person who raises the requests will stall on every request, and that is the control working, not a fault.

Example: if Priya Raman is the only administrator at HC Corp, a chain that asks “an administrator” to approve her own submissions has no valid approver. A second administrator, or a step that routes to her manager, is the fix.

What is expensive to change later

Decision	Cost of changing later
The shape of a chain that is already live	High. Requests already running continue on the version they started under, so for a period you are supporting two shapes at once and reading two sets of history.
An approver named as a specific person	Medium, and recurring. Every time that person changes job, someone has to remember this route exists.
Which requests the route applies to	Medium. Widening it can flood approvers with requests they were not expecting to see.
Deadlines, reminders, and escalation targets	Low. They take effect from the next published version onwards.
Step names and notification wording	Low.

What happens next

Once the shape is settled, build it in the designer, test it against sample data before it reaches anyone, and publish it. Bind it to the requests it should cover only when you are satisfied with the route it takes.