Approval Workflows People Actually Follow: A Design Guide

I have watched carefully documented approval workflows die within a month of go-live. The steps were correct, the sign-offs mapped the org chart perfectly, and the audit committee was happy. Then the people who actually raise requisitions found the side door: a phone call, a "just approve it and I will do the paperwork later", a batch of items split under the threshold. This guide is about designing approvals people follow because following them is the fastest path, not because a policy tells them to.

Why approvals get bypassed

Before designing anything, I look at why the current flow is being routed around. In almost every organisation the reasons cluster into four:

• Too many steps. A five thousand dirham purchase should not touch six inboxes. Every extra hop adds queue time, and queue time is where requests go to die.
• Unclear thresholds. If nobody can state from memory what value needs whose sign-off, people guess, and guessing means either over-escalating trivial items or splitting large ones to stay under a limit they half-remember.
• No delegation for absence. The single most common cause of a stalled request is an approver on leave with no delegate. The request sits, the requester chases, and eventually someone approves it informally to unblock the work.
• Approvers with no information at the point of decision. An email that says "Requisition 4471 needs your approval. Click here" tells the manager nothing. They either open five screens to reconstruct the context or, more often, approve blind. Blind approval is not control, it is theatre.

Notice that none of these are moral failings. They are design defects. Fix the design and the bypassing stops on its own. The rest of this guide designs around each one.

Design step one: clear delegation of authority

The foundation of any workable approval flow is a delegation of authority (DoA) matrix that anyone can read in ten seconds. Value bands, who approves, and how far it goes. When this is fuzzy, everything downstream inherits the fuzz. Here is the shape I use as a starting point, adjusted per organisation and currency:

Two rules make this matrix hold up. First, bands are ranges, not single figures, so nobody has to ask "what about 25,000 exactly?" Draw the boundaries and state which side each edge falls on. Second, the number of approvers grows with value but never runs away with it, which is a rule I will come back to. When the DoA is this legible, threshold confusion disappears and so does the incentive to split purchases.

The approval state model

Every request moves through a small set of states. The mistake I see most is treating approval as a one-way pipe with only submit and approve, which forces every exception into an out-of-band conversation. A workflow people trust has explicit states for the things that actually happen, including rejection with a reason and the ability to pull a request back. I describe the model as a state list rather than a picture so it stays exact:

The two states people forget are reject-with-reason and recall. A rejection with no reason is useless, so I make the comment mandatory and I feed it back to the requester verbatim so they can fix the actual problem. Recall matters because without it a requester who spots their own mistake has no clean way to stop the request, so they resort to messaging the approver "do not approve that one". Give them a button instead. If you want to formalise the notation behind this kind of model, BPMN is the standard for drawing it unambiguously.

SLA matrix and auto-escalation

A state model without timers is a wish. The single change that does most to keep requests moving is an escalation clock on every pending step, so nothing sits in an inbox indefinitely. I size the clock to the value and urgency of the request, not a single flat number, because a routine stationery order and a half-million capital item do not deserve the same patience.

The escalation is automatic, not a manual chase by the requester. When the timer fires, the platform reassigns the task, records that it escalated and why, and notifies the parties. This does two things at once: it unblocks the work, and it produces data on which approvers are consistently the bottleneck, which is a conversation worth having with the numbers in hand.

The rules that cut cycle time most

Once the DoA, the state model, and the SLAs are in place, a handful of design rules do most of the remaining work. These are the ones I reach for first because they compound:

• Parallel where the review is informational, sequential only where accountability stacks. If two people just need to be aware or give a soft opinion, send it to both at once and gate on both responses, not one after the other. Reserve strict sequence for the cases where a later approver is legally accountable for what the earlier one signed, because there the order is the control.
• A hard cap of four levels, regardless of value. Beyond four, each additional signature adds delay without adding real scrutiny, because the later approvers are trusting the earlier ones anyway. If a purchase genuinely needs more eyes, that is a board or committee decision, which is a single gate, not a fifth serial hop.
• Approve from email or Teams with enough context embedded. The approver should see the vendor, amount, budget line, requester, and business justification in the message itself, with approve and reject actions inline. Microsoft's Power Automate approvals is one way to deliver that inside a mailbox or a Teams channel so the decision happens where the manager already works.
• Raise the threshold before you add a step. The instinct when spend control slips is to add an approver. Usually the better move is to lift the auto-approve threshold so the small stuff flows and the scarce attention lands on the items that matter.

Out-of-office and joiner-mover-leaver

Two organisational realities break more approval flows than any technical fault: people go on leave, and people change roles. Both need to be designed in, not patched later.

Out-of-office delegation:

Every approver should be able to set a delegate for a date range, and the flow should honour it automatically. When the manager is out, the task routes to the delegate from the start rather than sitting until the escalation timer rescues it. The delegation is recorded, so the audit trail shows that the delegate acted with authority for a defined window and on whose behalf. Without this, leave is the number one cause of stalled requests, exactly the third failure mode I opened with.

Joiner, mover, leaver effects on the matrix:

The DoA matrix is tied to roles and people, and people move. When someone joins, they need to be placed in the matrix before their first request lands, not after it stalls. When someone moves, their old approval authority has to be revoked as their new one is granted, or you get gaps and overlaps where nobody or the wrong person can sign. When someone leaves, any request pending in their queue must reassign immediately, and their delegations must lapse. I treat the approval matrix as a live object that the identity and HR process updates, not a document someone remembers to edit twice a year. If your systems are connected, this is a natural place for that plumbing to earn its keep, which is a theme I cover in enterprise system integration explained.

The audit trail a finance auditor asks for

When a finance auditor reviews approvals, they are not impressed that things got approved. They want to reconstruct each decision. In practice they ask for a specific set of facts on every request, and if the workflow does not capture them the answer is a scramble through inboxes. I make sure the trail records:

• Who submitted, and when, with the original values
• Every approver in the chain, their decision, timestamp, and any comment
• Any rejection reason and the resubmission that followed
• Every escalation, why it fired, and who it reassigned to
• Any delegation in force at the time, and on whose behalf the delegate acted
• The DoA band applied and the authority that justified the final sign-off
• An immutable record, so a closed request cannot be quietly edited after the fact

The test of a good trail is whether an auditor can answer "why was this approved, by whom, under what authority, and could anyone have changed it afterwards?" without asking you a single follow-up. If the workflow produces that automatically, audits stop being fire drills.

Before and after: eight steps to three

Here is a real shape of change, anonymised. A client ran an eight-step requisition approval: requester, supervisor, line manager, department head, budget holder, finance clerk, finance manager, and procurement. Every purchase, from a box of gloves to a generator, walked the full chain. Average cycle time was eleven working days, and the workaround culture was thriving. Roughly a third of purchases arrived as emergencies precisely because the normal path was too slow to use.

We cut it to three steps. First, we raised the auto-approve threshold so anything under five thousand needed only the line manager, which removed most of the volume from the chain entirely. Second, we collapsed the middle: budget validation became a system check against the budget line rather than a human clerk, and the department head and finance manager reviewed in parallel for the mid band rather than in sequence. Third, we capped the chain at four levels for the largest items and let the SLA timers escalate anything that stalled.

The result was an average cycle time of just under two working days. The part that surprised the finance team was spend control. They had feared that fewer steps meant looser control, and the opposite happened. Because the compliant path was now the fast path, the informal approvals and the split purchases mostly stopped, which meant that for the first time the numbers in the system reflected what was actually being bought. Fewer gates, cleaner data, better control. That is the pattern almost every time: the discipline comes from a flow people follow, not from a flow that looks strict on paper.

Conclusion

Approval workflows are a design problem, not a compliance problem. Start from why yours gets bypassed, then answer each reason directly: a legible DoA matrix for the thresholds, an explicit state model with reject-with-reason and recall, SLA timers that escalate on their own, parallel review where accountability does not stack, a hard cap of four levels, decisions made where the approver already works, and delegation that survives leave and role changes. Do that and the fast path and the compliant path become the same path. For where this fits into the wider tooling decision, my workflow automation buyer's guide covers how to choose the platform underneath it.

A note on independence: I do not resell approval or workflow platforms and I take no vendor commissions. The products named here are mentioned because they illustrate a point, not because I earn anything from them. My advice is paid for by clients, not by software companies, and I recommend the smallest design that solves the actual problem.