A document process is controlled when four things are true at once:
- The rules are enforced by the system, not by the screen.
- Incomplete work cannot advance, and the refusal comes from the process rather than from a person.
- Decisions are recorded with authority — who decided, when, and against what the case looked like at that moment.
- The process ends by carrying out the operation, not by reaching a final folder.
Anything short of that is a convention. Conventions are followed carefully by people who are not busy, and this is the first sentence to argue with, because the disagreement is usually about whether that matters. It matters because the failures are silent: a convention that was skipped leaves no trace, so the first evidence you get is the outcome.
1. The rules belong in the domain, not in the interface
The common shape is a status field plus a screen that hides the buttons that should not be pressed. That is a helpful screen and it is not a control. It is enforced exactly where it is drawn, which means an import, an integration, a script, or a second interface written later all walk straight past it.
A controlled process states its transitions once, centrally, and refuses the ones that are not allowed wherever they are asked for. The practical test is simple: if somebody calls the API directly and asks for a transition the flow does not permit, does it fail? If the answer is "it would not happen because the button is hidden", the rule is a convention with a nice presentation.
2. Completeness is a condition, not a reminder
Most document processes have a list of what a case must hold. The question is what that list actually does.
If it is a checklist somebody ticks, it does nothing: it records that a person believed the case was complete. If it is a set of required documents the process declares, and the case is created already knowing them, then completeness becomes something the system evaluates — and submission can be refused while a mandatory document is missing.
That refusal is the control. Not the list; the refusal. It is also where the design earns or loses the people using it: a hard block that says "this cannot proceed" is only tolerable when it says which document is missing and lets them fix it there and then. A block without that is how shadow processes get invented.
3. A decision is about a state, not about a case
This is the part most often missed, and it is the one that hurts in an audit.
An approval given on Tuesday was given against the documents and field values as they stood on Tuesday. If somebody edits the case on Wednesday and the approval is still shown as valid, the record now says somebody approved something they never saw. Nobody did anything wrong, and the record is wrong anyway.
Controlling this needs two things. The approval has to be recorded against the state of the case at that moment, and any later change has to invalidate it — the case returns for a decision instead of carrying an approval that no longer refers to anything. Where approval is a chain, the same logic applies per approver: one at a time, in order, each with their turn on record.
4. The end of the process is an operation, not a folder
A process that finishes by moving a case to "Completed" has documented that work should happen. Somebody still has to go and do it — usually in another system, usually by retyping. That retyping is where the process actually leaks: it is unlogged, unvalidated, and invisible to everything upstream.
A controlled process ends by calling the system that owns the operation and closing with the reference that comes back. The work finishes where it counts, and the case carries the proof that it did.
What to fix first
If you are looking at an existing process and want the largest gain for the least work, the order is almost always this:
Start with the refusal. Pick the one transition that most often happens too early — usually submission with something missing — and make the system refuse it. It is a small change and it is the one people feel immediately.
Then move the rules out of the screen. Not all of them; the one or two that would be most damaging to bypass.
Then fix the approval record, so a decision names the state it was made against.
Leave the integration for last. It is the most valuable and the most expensive, and it is much easier to build once the case reaching it is guaranteed to be complete and decided.
None of these steps requires the previous one to be finished, but they are in this order for a reason: each one makes the next cheaper, and the first one is the only one you can do this week.
