Automation does not remove an unclear workflow. It makes the ambiguity run faster and in more places.
A useful workflow map records the decision, trigger, information, state, owner, system change and exception at every meaningful point. The map must describe the business work, not merely the screens a person clicks.
Begin with the outcome and trigger
Name the outcome in business terms: a verified supplier is ready for an approved purchase, not “the form is submitted”. Then define the trigger precisely. Is work created by a signed agreement, a complete request or an email someone interprets? If different people recognise different starts, automation will inherit duplicate or premature work.
OMG's BPMN specification provides a standard graphical notation for business processes and distinguishes process semantics from a particular implementation environment. A full BPMN model may be appropriate for complex implementation. The netlinkE canvas below is a smaller discovery instrument for deciding whether the workflow is ready to automate.
The workflow mapping canvas
| Field | Question | Evidence |
|---|---|---|
| Outcome | What observable condition means the work is complete? | Acceptance rule and accountable owner |
| Trigger | What event creates one instance of work? | Event, identifier and duplicate rule |
| Decision | What business judgement changes the path? | Decision rule, authority and input |
| Information | What is needed, where did it come from and how current is it? | Source, owner and validation |
| State | What is true before and after this step? | Named state and system of record |
| Handoff | Who or what receives responsibility next? | Queue, response expectation and acknowledgement |
| Exception | What prevents the normal path? | Exception class and detection rule |
| Recovery | How does work return to a known state? | Retry, compensation or manual procedure |
| Measure | What proves improvement without hiding quality loss? | Baseline, outcome and guardrail |
Separate decisions from interface actions
“Open the spreadsheet” and “click approve” are interface actions. The business decisions are why a case is eligible, which evidence is sufficient and who is authorised to accept the consequence. When a map contains only clicks, the implementation team must rediscover the policy during development.
For each decision, identify its input, rule, owner and output state. Some decisions can be deterministic. Some require professional judgement. Some can be assisted but not delegated. Automation choice follows that distinction.
Trace state across systems
Many workflow failures are state failures: two systems disagree, a handoff has no acknowledgement, or a partial update leaves work looking complete when it is not. Give each work item a durable identifier and name the system of record for each important fact. Record the state before and after an integration writes.
Do not use “in progress” as a universal state. Distinguish awaiting information, awaiting approval, action in progress, failed and complete. Each state needs an owner and an allowed next transition.
Treat exceptions as part of the workflow
Observe representative cases and list exceptions by cause: missing information, invalid information, policy conflict, external dependency, duplicate event, unavailable system or authority threshold. Count them where possible. A rare exception with severe consequences may matter more than a frequent inconvenience.
Choose an intervention only after seeing this distribution. A deterministic rule may handle stable cases. A workflow engine may coordinate state. AI may assist classification or preparation where inputs vary. A person may remain the correct decision-maker. The solution can combine them.
What the map prevents
Use five failure tests before implementation:
- Duplicate-work test: Could two triggers create the same work?
- Ownership test: Can any state exist without an accountable owner?
- Hidden-exception test: Does the normal path omit a known failure class?
- Recovery test: Can a partial action be detected and reconciled?
- Unreliable-state test: Could automation move a record whose truth is unresolved?
If any answer is yes, repair the operating condition or explicitly bound the risk before automating.
Validate with real cases
Walk the map with operators, owners and implementers. Use normal cases, edge cases and recent failures. Compare observed work with the documented path. Then pilot one bounded slice and measure outcome time, quality, exception rate, recovery effort and manual intervention.
The objective is not to eliminate every human step. It is to place each decision and action where it can be performed reliably, observed clearly and recovered safely.
Sources and scope
OMG BPMN is cited as external modelling context. The workflow mapping canvas and five failure tests are original netlinkE framework and recommendation.
