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 editor

2. 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 editor

3. 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 editor

4. 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 editor

5. 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 editor

6. 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 editor

7. 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 editor

8. 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 editor

9. 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 editor

Reading the patterns

Symbols unfamiliar? The reference covers all of them. Or start smaller with the first-process tutorial.