Examples
BPMN examples — nine processes you can open and edit
Each example below ships as a template in the free editor. The "Open in editor" links load the full diagram — editable, validated, and yours to save. Every one demonstrates a pattern you will reuse constantly.
1. Approval chain
The backbone of internal operations: a request passes through manager and director review in sequence, each decision modeled as an exclusive gateway with labeled outcomes and a default rejection path. The pattern to steal: both rejection routes converge on a single "send rejection with reason" step, so the exit behavior is defined once instead of being duplicated per stage.
Open in editor2. Exception handling with an escalation timer
A support ticket is handled normally, but an interrupting timer boundary event on the handling task fires after 48 hours without resolution: a supervisor takes over and the customer is notified of the delay. This is the standard BPMN answer to SLA breaches — the escalation is in the model, not in tribal knowledge.
Open in editor3. Four-eyes review
Two reviewers work between a parallel split and join — neither waits for the other — and an exclusive gateway after the join checks that both approved. A rejection sends the document to rework and back through review. Note what the parallel join guarantees: the decision cannot happen until both reviews exist. Compliance teams call this the four-eyes principle; BPMN makes it structural.
Open in editor4. Onboarding / KYC
A customer application crosses two lanes in one pool: the applicant submits documents; compliance verifies identity, runs a risk assessment as a business-rule task, and routes by risk level. Every lane crossing is a handoff — exactly where onboarding stalls in practice — and modeling them makes the stalls visible and countable.
Open in editor5. Claims intake
An insurance claim is validated for completeness. Incomplete claims trigger a request for missing information, then the process waits — a message catch event — until the claimant responds, and validates again. The loop makes an honest statement most process docs hide: at this point we are blocked on the customer, for as long as it takes.
Open in editor6. Incident escalation
Triage routes by severity: critical incidents go to immediate resolution with a one-hour interrupting timer that hands stalled fixes to a manager; minor ones are logged and scheduled. Three distinct end events — resolved, escalated, scheduled — mean an incident report can say precisely how instances finished.
Open in editor7. Procure-to-pay
The full purchasing cycle: requisition, approval, purchase order, goods receipt, then a message catch event for the supplier invoice, and a three-way-match gateway before payment. Discrepancies route through a resolution task and then to payment. The catch event is the honest part — the process genuinely waits on an external party it does not control.
Open in editor8. Order fulfillment
An order is checked against stock. In-stock orders fan out into parallel picking and invoicing before shipping; out-of-stock orders trigger a backorder, and the process waits on a message from the supplier before checking stock again. One diagram, both patterns most fulfillment processes need: parallel work and an external-wait loop.
Open in editor9. Refund with response deadline
A refund request is reviewed; approved requests are paid out directly. Borderline cases get an offer of store credit — and then an event-based gateway waits for whichever happens first: the customer accepts, or seven days pass and the case closes as expired. "First of these events wins" is exactly what the event-based gateway exists for; no combination of ordinary gateways can express it.
Open in editorReading the patterns
- Exclusive gateway + default flow appears in every example — the discipline that survives contact with reality.
- Boundary timers (examples 2 and 6) express deadlines where they apply, not as global footnotes.
- Message catch events (examples 5, 7, and 8) mark where the process waits on outsiders.
- Parallel split/join pairs (examples 3 and 8) guarantee synchronization structurally.
- Event-based gateways (example 9) race an expected reply against a deadline.
- Lanes (example 4) turn handoffs into visible, checkable structure.
Symbols unfamiliar? The reference covers all of them. Or start smaller with the first-process tutorial.