The Approval Workflow That Can't Lose a Step
Picture an approval as a chain. A request enters at one end, passes through every hand that needs to touch it, and emerges at the other end as a decision that can be defended. The chain works only if every link holds. The trouble is that most organizations build their approval chains out of links that look strong and aren't — a forwarded email here, a verbal yes there, a name initialed on a printout that lives in one person's drawer.
Lose one link and the chain doesn't snap loudly. It just quietly stops being able to bear weight. Months later, when someone asks the project to show its work, the chain that felt complete turns out to have two or three links that left no trace. The decision still happened. It simply can no longer be proven, which in a regulated, audited or disputed context is almost the same as not having happened at all.
Where chains break without a sound
The break is rarely the dramatic one — a rejected request, a flagged exception. Those get attention precisely because they interrupt the flow. The dangerous breaks are the approvals that sailed through smoothly. A manager replies "looks good, go ahead" from a phone at an airport. The work proceeds. The reply is buried in a thread that is never linked to the deliverable. Everything functioned perfectly, and yet six months later the step is unreconstructable.
This is why counting your approval steps on paper tells you almost nothing. What matters is not how many steps your process defines, but how many of them survive the handoff as findable, dated, attributable evidence. A six-step process that leaves two records is, for any practical purpose, a two-step process wearing a six-step costume.
Designing a chain that can't lose a step
A durable approval workflow has three properties, and they are not exotic. First, every step writes its own record automatically, as a consequence of the step happening, not as a separate task someone has to remember. Second, the record is attached to the thing being approved, not floating in a parallel system, so the approval and the work travel together. Third, the chain is visible while it is in motion, so a stalled step announces itself instead of hiding until an audit surfaces it.
Make recording automatic. If approving and documenting are two separate actions, the second one will be skipped under pressure. Collapse them into one.
Bind the approval to the work. An approval that lives somewhere other than the thing it approves is a future scavenger hunt. Keep them in the same place.
Keep the chain visible in flight. A pending step you can see is a nudge. A pending step you can't see is tomorrow's gap.
The payoff is boring, which is the point
A well-designed approval chain produces no drama. Nobody reconstructs anything from memory. No one searches three inboxes the night before a deadline. The auditor asks who approved the change and the answer is one click away, dated and attributed. The goal of approval design is not to add ceremony; it is to make the question "can you prove it?" so easy to answer that nobody dreads being asked. When the boring answer is always available, the chain has done its job.
We map more of these break points — and the small design choices that close them — across our process and accountability series. Most broken chains were never designed to break; they were just never designed to leave evidence.
