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, with Reject → Rejected.
- Any one sends it back for correction, with Send back and a reason → Returned. The decisions already taken stand, and when the author submits again the turn goes back to whoever sent it back. If the correction touches anything material — a file, or the value of a required field —, the chain restarts on its own the moment the author saves (see the last section).
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 stays Rejected. It is not a final state, but it does not move on its own either: whoever may submit the Dossier — the person who created it, or somebody who manages one of its units — sees Reopen dossier, and reopening asks for a reason. The case goes back to Returned, to its author, for correction. The approval round that ended in the rejection is kept as a round of its own, and the chain starts again with every approver undecided, rather than carrying stale acceptances into a second round. The reason stays in the history.
That restart is the correct behaviour and worth understanding. If the case was rejected and is going to be corrected, the earlier approvals were given to a version that is about to stop existing.
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.
The product answers half of the test itself: the person who created the Dossier cannot be one of its approvers. Naming them is refused — on the Dossier or when adding an approver to a Dossier in progress — unless that person holds the permission Decide a dossier one created, a critical permission whose use is audited. And only somebody who holds the permission to approve can be an approver. The other half is yours: whoever prepared the case without having created it — a teammate, the person who gathered its documents — is not caught by this rule, and it is the roles that decide whether they approve too.
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.
DOK Genius uses the second, and defines "material" itself: the Dossier's files and the values of its required fields. Every decision is stamped with the version of that content. When a save changes it under decisions already taken, the chain restarts in that same save: the decisions move to an archived round, marked as invalidated by a material change, and whoever had decided is told. A change to an optional field, a tag or a comment restarts nothing.
What is left to your organisation is the edge of that rule. A piece of data that, once changed, should force a new decision has to be a required field of the Process, or sit in a file; if it is optional, the rule does not see it. And it is the Process as it stood when the Dossier was created that counts: making a field required later only holds for the Dossiers that follow. Go through each process's fields with that question.
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, with its reason, so you have seen the chain restart.
- One sent back and submitted again with no material change, so you have seen the decisions stand.
- An honest answer to the "can the preparer approve it?" test for each of your nine processes.