Collect the decisions before drawing the diagram
Ask an operator to show a recently completed case, a delayed case and a rejected case. Capture the source, requested outcome, evidence, decision owner and next step. Include spreadsheets and informal messages if they actually carry the work. A map of the documented policy alone can miss the handoffs people perform to make the policy work.
Consider an equipment request: the requester supplies a specification, IT confirms compatibility and a budget owner authorizes spending. Purchasing then prepares an order. If the specification changes during review, the case returns for checks on the new version. Drawing those dependencies exposes more than a row of application logos.
Use a small useful vocabulary
| Element | Question |
|---|---|
| Task | What observable work happens here, and who performs it? |
| Decision | Which rule selects the next permitted path? |
| Wait | Which message, deadline or external result resumes work? |
| Outcome | Which evidence proves this branch finished? |
BPMN gives these concepts a shared notation. Camunda documents an exclusive gateway as selecting one outgoing path using process data. Its parallel gateway starts concurrent paths and, when joining them, waits for every incoming path. Exclusive gateway; parallel gateway. Keep that distinction visible even when using a simplified planning sketch.
Label a decision with a question and its outgoing paths with explicit conditions. “Approved?” is usable when approval refers to a named decision record. “Looks good?” is not an implementation contract. Define the default route for unmatched or incomplete information.
Walk a case through the map
Take request ER-28 for 12 monitors. The specification is complete, so compatibility and budget checks can start in parallel. Compatibility passes. The budget owner asks for a lower-cost configuration. The case is still unresolved: one completed check cannot release an order.
Case handoffs
- Receive
- Identify the case
- Check
- Resolve missing inputs
- Decide
- Apply explicit criteria
- Confirm
- Record the outcome
| Evidence | Meaning |
|---|---|
| Receive | Identify the case |
| Check | Resolve missing inputs |
| Decide | Apply explicit criteria |
| Confirm | Record the outcome |
Planning sketch; gateways need explicit conditions.
The requester submits revision 2. Decide which checks need repeating. If the configuration changed, the old compatibility result cannot automatically cover it. If only a delivery contact changed, a narrower recheck may be appropriate under the agreed policy. Record the reason rather than treating every edit identically.
Finally, both required checks accept revision 2. Purchasing creates a draft. The map should show whether issuing that draft is a separate authorized action and whether confirmation from the target system is required before the case reaches Ordered.
Draw waiting as a real state
A supplier response can arrive hours after the invitation. Show the invitation, a waiting state, the matching response and the deadline behavior. Do not represent the supplier as a synchronous function that always returns a quotation.
Define late replies, declines, bounces and unanswered questions. A timeout can create a buyer task without cancelling the purchase. A response received after cancellation should remain linked as history without reopening the request automatically.
Human decisions need the same treatment. A manager being absent is not an exception the model can guess through. Show the delegation or escalation rule and the person authorized to apply it. Avoid loops that keep creating reminders without an eventual owner.
Expose crossings between teams and systems
For every handoff, write the case identifier, payload, expected acknowledgement and authoritative record. If one team sends a file and the next team types its contents again, mark that boundary. It is a candidate for automation, provided the receiving team can validate the fields and reject ambiguous inputs.
Keep the business map separate from its technical implementation. “Confirm approved specification” remains a business responsibility whether the evidence lives in Drive, SharePoint or an ERP. The connector map can then show the actual reads and writes without changing that responsibility.
Validate the paths that do not finish cleanly
Use a checklist of withdrawn requests, missing evidence, simultaneous edits, absent approvers, unavailable systems and late confirmations. Trace each one to a visible state with an owner and permitted next action. A branch that ends at “error” still lacks an operating process.
Ask the requester, reviewer and operator to read the map independently. Resolve disagreements about completion before building. Give Trion the agreed map, decision criteria and recovery cases.