The process, written down and enforced.
State machines rather than reminders. Approvals route by amount, role, and site. Escalations fire on time, every time, whether or not anyone is watching the queue — and the rule acts on the document rather than sending a notification about it.
Visual builder·Conditional routing·Timed escalation
What you can put under a workflow.
Any record type, including the ones you add yourself. The distinction that matters throughout is between a rule that acts and a rule that notifies.
States and transitions
What a document can be, and what it may become.
Explicit states
Every document type gets named states and the transitions allowed between them. An undefined transition is refused, not warned about.
Ownership per state
Which role holds the document in each state, so 'who has this' is a field rather than a conversation.
Entry and exit conditions
A document cannot enter a state until its conditions are met — a required attachment, a passed inspection, a credit check.
In-flight behaviour on change
Publishing a new version applies from the next document. Work already moving finishes on the path it started on.
Parallel branches
Two approvals that do not depend on each other run at the same time instead of queueing behind one another.
Approval matrices
Who decides, chosen from the record rather than from a rota.
Route by any field
Value, cost centre, site, supplier, item group, project, or a dimension you defined — not just amount.
Bands rather than a single threshold
Under five hundred goes straight through, under five thousand needs a manager, above that needs two. Bands, not a cliff.
Derived approvers
The approver resolved from the reporting line on the employee record, so a change of manager does not need a workflow edit.
Delegation with an end date
Cover during leave that expires on its own, rather than a permission somebody forgets to remove.
Segregation of duties
The person who raises it cannot be the person who approves it, enforced rather than trusted.
Time
What happens when nobody does anything.
Timed escalation
If nobody acts within the window, it moves up. Nothing sits in a queue unseen because somebody is on leave.
Working hours aware
The clock runs against a calendar and a holiday list, so an overnight window is not a breach on Monday morning.
Reminder before escalation
A nudge to the current owner before it is taken off them, which resolves most of them without an escalation at all.
Ageing visible
How long each item has been where it is, so a queue with a problem looks different from a queue that is busy.
Scheduled work
The recurring things that otherwise depend on memory.
Recurring postings
Accruals, deferrals, depreciation, and standing journals on a calendar rather than a checklist.
Reorder and planning runs
Stock checks against projected quantity, and production plans, on a schedule with a notified recipient.
Statements and packs
Customer statements, supplier remittances, and reporting packs generated and sent on their own cadence.
Period tasks
The close checklist as scheduled items with owners and due dates, rather than a spreadsheet somebody maintains.
Events out
How the rest of your estate finds out.
Every state change emits
An event other systems can subscribe to, with the document, the transition, and the actor.
Webhooks with retry
Delivery retried with backoff, and failures visible as records rather than as a silent gap.
Replay
Re-deliver events over a window after fixing a downstream outage, instead of reconciling by hand.
Agents as subscribers
An agent can be triggered by the same event as an external system, using the same mechanism.
From a rule in someone's head to a rule in the system.
Step three is the one that matters and the one usually skipped: you can run last year's documents through a draft workflow and see where they would have gone.
- 01
Describe
Name the states a document moves through and who owns each one.
- 02
Condition
Add the thresholds — value, variance, site — that decide which path it takes.
- 03
Test
Run historic documents through it and see where they would have gone.
- 04
Publish
It applies from the next document. In-flight work finishes on the old path.
The specification.
The behaviours that decide whether a workflow engine survives contact with a real approval chain.
- Scope
- Any record type, including custom ones
- Routing inputs
- Any field on the record, plus derived reporting line
- Concurrency
- Parallel branches with a join condition
- Clock
- Working-hours calendar and holiday list aware
- Versioning
- In-flight documents finish on the version they started on
- Testing
- Dry run against historic documents before publish
- Events
- Emitted per transition, with retry and replay
- Segregation
- Raiser cannot approve, enforced at transition
Where a workflow is the wrong tool.
Automating the wrong thing makes it permanent, so these are worth reading before you build.
- It will not fix a bad approval chain
- Four unnecessary approvals executed automatically are still four unnecessary approvals. Remove steps before you automate them.
- It is not a substitute for a limit
- A workflow routes a decision to a person. It does not decide. Where the decision is rule-shaped, put the rule in the document, not in a routing step.
- It does not orchestrate agents
- Sequencing several agents on one record is a different problem with different failure modes — that is orchestration, and it has its own page.
- It will not rescue bad master data
- Routing by cost centre requires cost centres that mean something. Workflow makes data quality visible rather than optional.
Next step