Designing approval automation as a state machine
A fictional automation case: approvals as designed states, not as emails and checkboxes.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
Each request is in exactly one visible state; changes invalidate exactly the approvals they affect; waiting has a clock and a next approver; every decision is on record.
Approvals are a chain of emails: nobody knows which decision is pending, rejected quotes come back as edits, and changed prices keep old approvals.
Which changes invalidate an approval—and where must the process restart?
Model the two decisions as states of one approval machine, with invalidation rules per data change, instead of a single approval step.
Commercial deals outside standard terms need commercial approval, and new credit exposure needs financial validation. The current automation sends emails and ticks a checkbox. Rejections come back as edits to the same request, and a price changed after approval keeps the approval.
A seller submits a deal that is outside standard terms or adds credit exposure.
- Commercial and financial decisions recorded separately
- Approved state valid only for the approved data version
- Rejections carry a reason
- Escalation fired when a clock ran out
02The reality · current state
What the automation does today.
- Nobody can tell which decision is pending, or with whom
- Rejections and requests for changes look the same
- A price change after approval keeps the old approval
- Approvals wait indefinitely when the approver is away
- History is scattered across inboxes
03Target steps
Each step with its mode, its actor and its guard.
- 01Submitted
Data version frozen with the request.
- 02Commercial review
Terms within strategy? Approve, reject or return.
- 03Route to finance
Only when credit exposure changes.
- 04Financial review
Credit and payment terms acceptable?
- 05Approved
Approval attached to the data version; downstream unblocked.
04Key dimension · Approval states, invalidation & re-entry
Two decisions, one machine
Rejected and returned are different outcomes. Resubmission is a new decision on a new version—not an edit.
Commercial review
Waiting on the sales manager’s decision, with a clock.
- Commercially approvedSales manager approvesPerson
- Returned for changesSales manager asks for changesPerson
- RejectedSales manager rejectsPerson
- Escalated · commercialNo decision within two working daysTimer
Entered from Submitted, Escalated · commercial, Resubmitted.
| When this changes | It restarts |
|---|---|
| Price, discount or product mix | Commercial review (and finance if exposure changes) |
| Payment terms or credit limit | Financial review only |
| Delivery date or contact | Nothing: not part of either decision |
| Customer legal entity | Both decisions |
Delegation is a recorded assignment with scope and dates—never a shared login. Silence never approves.
05Execution safety
If it can run twice, it is designed to run twice.
Short automated steps between long human waits; the state must survive days and be auditable.
- Version binding
- Approval valid for the data version it was given on
- Invalidation
- Declared per field: which change restarts which decision
- Timer
- Reminder, then escalation to a named next approver
- History
- Every transition with who, when, version and comment
06Exceptions & recovery
Not every failure is a retry.
- Approver absent ConfigurationOut-of-office or no delegateRoute to the declared delegate or next levelSales operations
- Data changed after approval Stale stateVersion mismatchInvalidate the affected decision onlyAutomation
- ERP unavailable when approved Dependency · retryDownstream call failsApproval stays; downstream queuedPlatform team
- Final rejection RejectionApprover decisionEnd with reason; seller notifiedSeller
07The trade-offs
Credible options, judged against these premises.
One approval step for everything
One approver, one kind of risk
Cost: Merges two decisions; wrong evidence for bothEmail-based approvals
Very rare exceptions
Cost: No state, no history, no clockApproval state machine with invalidation and timers
Recurring approvals with two owners
Cost: Invalidation rules must be maintained08The second layer
Questions that change the design.
Decisions
- Do commercial and financial approval represent different decisions?
- Can approval be delegated?
- Who owns escalation?
Change
- What data invalidates prior approval when changed?
- When must approval restart?
- Is a resubmission a new decision?
Time & record
- What happens after timeout?
- How is history retained?
- What does the seller see while waiting?
09Decisions & outputs
What the work produces.
- 01Approval state machine
- 02Invalidation matrix
- 03Escalation clocks
- 04Delegation rule
- 05Approval history model