Collecting a signature is the easy quarter of the problem. The other three quarters stay invisible until somebody disputes a decision, and they are what this chapter is about.
Set one up
Go back to your Motor claim - third party process, open Approvers, and add three people in this order:
- Claims handler — the person who knows the case.
- Claims manager — the person who carries the budget.
- Head of claims — the person who owns the risk.
Save. Every new dossier of this process now carries that chain.
Why the order is not decoration
Each step exists because the previous one happened. The manager approves a case somebody has confirmed is correct; the head of claims countersigns something the budget holder has accepted.
Ask everybody at once instead — first to click wins — and you throw that away. The budget holder approves before anybody has checked the case is even right, and their approval quietly means less than the record suggests.
Ordering also buys you something for free: at any moment there is exactly one person the case is waiting for. "Who is this with?" becomes a question with an answer.
Watching it happen
Submit a dossier of this process. Because it has approvers, it routes to Waiting decision rather than to processing.
- The first approver sees it. Nobody else is asked yet.
- They approve → the case moves to Partially approved, and the second approver is asked.
- All three approve → it continues to processing.
- Any one rejects → Rejected.
- Any one sends it back for correction, with a reason → Returned, and the chain starts again over the corrected version.
Partially approved earns its place
When a chain has three approvers and one has said yes, the case is not "approved" and it is not "pending" either. Systems without that state end up tracking it outside themselves — a column in a spreadsheet, a convention about email subject lines — and from that moment the real state of a case lives in two places that disagree.
Rejection, and what happens next
A rejection is a decision, not an error. The approver has to say why — a rejection without a reason is refused — and that reason is what makes the rejection legible six months later.
A rejected case goes one place: Returned. Reopening resets every approver to pending and clears the failure fields, so the case starts its chain again rather than carrying stale acceptances into a second round.
That reset is the correct behaviour and worth understanding. If the case is being corrected, the earlier approvals were given against a version that no longer exists.
Authority is not access
Opening a case, editing it and approving 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 anybody's bad faith, just because the system never distinguished them.
The test is blunt, and worth running against every process you configure: can the person who assembled the case approve it? If the answer is yes, the approval records that somebody agreed with themselves.
What a good approval record holds
| Who | The approver |
| What | Approved or rejected |
| When | The moment it was recorded |
| Where in the chain | Their position, and therefore who was waiting behind them |
| Why | Their comment |
Five of the six things that matter. The sixth is the subject of the next section, and it is the one most approval systems never answer.
The question worth asking of any approval system
An approval given on Tuesday was given against the case as it stood on Tuesday.
If the case is edited on Wednesday and the approval still shows as valid, the record now asserts that somebody approved something they never saw.
There are two defensible answers to this:
- Invalidate on any change. Simple, safe, and occasionally annoying — a corrected typo restarts the chain.
- Invalidate on material change. Better in practice, and it requires you to define "material", which is real work and worth doing.
There is a third answer, and it is not defensible: leave the approval standing and hope nobody edits anything.
In DOK Genius, reopening a case resets its chain. When configuring your own processes, be deliberate about what an edit means in your organisation, and write it down — this is a policy question that a product cannot decide for you.
What you should have now
- One process with an ordered chain of three.
- One dossier that has passed through Waiting decision and Partially approved.
- One rejected and reopened, so you have seen the reset.
- An honest answer to the "can the preparer approve it?" test for each of your nine processes.