Many approval processes start with a sensible control: somebody should review a payment, discount, contract, purchase or exception before the business commits. Over time, more reviewers are added, thresholds are rarely revisited, and the approval path becomes the default answer to uncertainty.
The result is a queue disguised as governance. Work waits because the organisation has not made clear which decisions are routine, which need expert input, which require formal authority and which should be blocked automatically.
McKinsey has argued that decision frameworks can fail when too many stakeholders effectively receive a vote or veto and when the organisation does not distinguish who contributes input from who actually decides. That is directly relevant to approval design.
A good control stops the wrong work. A bad approval process stops all work until somebody has time to look at it.
Find the decision inside the approval
For each approval step, ask what decision the approver is making. If the answer is vague—“checking”, “signing off” or “making sure everything is okay”—the control may not be defined well enough.
Specify the risk, threshold or policy the approver is responsible for. If a system can verify a fixed rule, the workflow may not need human judgement at that point. If judgement is required, the approver needs the information and authority to make the decision rather than simply forwarding it to somebody else.
Reduce serial approvals
Serial approval chains multiply waiting time. A request can spend far more time idle than being reviewed. Separate approvals that truly depend on one another from reviews that can happen in parallel, and remove people who are only being kept informed.
Use value, risk or exception thresholds. A routine low-risk request may be auto-approved or handled by one role, while unusual or high-value cases escalate. This keeps human attention focused where judgement adds value.
Design for expiry, escalation and absence
Automation does not remove queue design. Microsoft's current Power Automate documentation notes that approval flows can have waiting limits and that abandoned approvals can remain visible after the waiting flow has failed. The specific platform limits are a technical detail; the operating lesson is universal: every approval needs a path for no response, expired requests, unavailable approvers and ownership changes.
Define escalation times, delegate rules, cancellation behaviour and what happens when an approver leaves the organisation. Monitoring should show aged approvals and failure states rather than forcing requestors to chase individuals manually.
Separate control from ceremony
Some approvals exist because “we have always required a manager”. Test whether the step still reduces a real risk. If the same approver accepts almost every request, the process may be better served by a clear policy, automated threshold and retrospective exception review.
Removing unnecessary approvals is not removing governance. It can strengthen governance by making the remaining decision points explicit, measurable and accountable.
What better looks like
A mature approval workflow has a clear decision owner, a defined risk or policy purpose, the minimum necessary participants, thresholds that route routine and exceptional work differently, time-bound escalation, and evidence that can be audited later. Requestors can see status without chasing. Managers can see where queues accumulate.
If approvals routinely delay customer work, purchasing, billing or delivery—and nobody can explain what each approver uniquely contributes—the workflow should be redesigned before it is automated further.