Most systems can collect approvals. A button, a name, a timestamp. The reason approval workflows still go wrong is that collecting a signature is the easy quarter of the problem, and the other three quarters are invisible until somebody disputes a decision.
Here is what actually has to be true.
Order is part of the decision
When approvals are gathered in parallel — everybody asked at once, first to click wins the race — the sequence carries no information. That is fine when approvers are interchangeable, and they usually are not.
A typical chain is reviewed by the person who knows the case, then approved by the person who carries the budget, then countersigned by whoever owns the risk. Each step exists because the previous one happened. Asking all three simultaneously means the budget holder approves before anybody has confirmed the case is even correct, and their approval quietly means less than the record suggests.
Ordering also produces something valuable for free: at any moment there is exactly one person the case is waiting for. "Who is this with?" becomes answerable, and the queue stops being a mystery.
Authority is not the same as access
Approval is where these two get conflated most often, and it is the conflation that turns a control into a formality.
Being able to open a case, being able to edit it, and being able to approve it are three different permissions. When they collapse into one, the person who prepared the case can approve it, and the separation the whole chain exists to create is gone — not through malice, just because the system never distinguished them.
The test is blunt: can the person who assembled a case approve it? If yes, the approval records that somebody agreed with themselves.
A decision is made against a state, not against a case
This is the failure that survives every other control, and it is worth being precise about.
An approval given on Tuesday was given against the documents and values as they stood on Tuesday. If the case is edited on Wednesday and the approval is still displayed as valid, the record now asserts that somebody approved something they never saw.
Nobody did anything wrong. The record is wrong anyway, and it is wrong in the specific way that an auditor is trained to look for.
There are two honest resolutions, and which one you pick is a real product decision:
- Invalidate on change. Any edit after an approval sends the chain back. Safe, and irritating when the edit was a typo in a phone number.
- Invalidate on material change. Only edits to the fields and documents the decision depended on reset it. Kinder to use, and it requires you to state, in advance, which parts of a case a decision actually rests on.
The second is better and costs a conversation nobody has had yet. The first is defensible. What is not defensible is the third option — leaving the approval standing and hoping nobody edits anything.
Partial approval is a state, not a spreadsheet
When a chain has three approvers and one has said yes, the case is not "approved" and it is not "pending" either. It is somewhere specific, and it needs a name.
Systems that lack that state end up tracking it outside themselves — a column somewhere, a convention about email subjects — and the moment that happens, the real state of a case lives in two places that disagree. Naming it in the workflow costs nothing and removes the shadow system.
What a good approval record contains
Six things, and if any are missing you will feel it in the first dispute:
- Who decided.
- What they decided — approved, rejected, or returned for correction.
- When.
- Against what: the state of the case at that moment.
- Their position in the chain, and who was waiting behind them.
- Any comment they left, particularly on a rejection.
The fourth is the one most often absent and the one that does the work. Without it you have a name and a date attached to something that has since changed shape — which is not a record of a decision, it is a record that a decision happened.