An online shop receives an order, checks stock, then charges the card and packs the parcel at the same time before shipping. This page draws that process in BPMN 2.0 (Business Process Model and Notation), the OMG standard for business processes. BPMN is not UML: UML covers software structure and behaviour; BPMN, swimlanes and journey maps are the other standard notations used alongside it when the subject is how a business works.
1. The Diagram
The Customer pool is collapsed (a black box). We do not model the customer's internal steps, only the messages they exchange with the shop.
A message flow (dashed, circle at the tail) carries the order into the shop and triggers the message start eventOrder received in the Sales lane.
Sales performs Check stock, then an exclusive gateway (X) asks In stock?. Exactly one outgoing path is taken.
If not, Sales sends an out-of-stock email (another message flow back to the customer) and the process ends at Order rejected.
If yes, a parallel gateway (+) splits the flow: Warehouse picks and packs while Finance charges the card. Both tokens run at once.
The second parallel gateway is a join: it waits until both branches arrive. Nothing ships before the card is charged.
Warehouse ships the order and the process ends with a message end event that sends the shipping notice to the customer.
2. How to Read It
Events are circles (thin = start, double = intermediate, thick = end), activities are rounded rectangles, gateways are diamonds. Solid arrows are sequence flows and may never cross a pool boundary; between pools only dashed message flows are allowed. Lanes divide one participant by role or department.
3. Variant: Waiting for Payment
Real orders often wait for an external event, such as a bank transfer. An event-based gateway (diamond with a pentagon in a double circle) waits for the first of several events: a Payment received message releases the order; a 48 hours timer cancels it and returns the stock. Drawing the timeout explicitly is one of the main reasons to use BPMN over a plain flowchart.
4. Pros, Cons, and When to Use
Pros
An ISO standard (ISO/IEC 19510) understood by analysts, auditors and process engines.
Pools and message flows show clearly where one organisation hands work to another.
Rich event types make timeouts, errors and messages explicit instead of implied.
Executable: engines such as Camunda and Flowable run BPMN XML directly.
Lanes make ownership of every step visible.
Cons
Over 100 symbols; most readers know only a dozen.
Detailed models become large and need tooling to stay tidy.
Easy to mix sequence and message flows incorrectly, which makes the model invalid.
Less suited to software internals such as classes or API calls.
Diagram-as-code support in common docs tools is weak.
When to use
Cross-department processes such as order-to-cash, onboarding or claims.
Processes you plan to automate in a workflow engine.
Compliance and audit work where timeouts and exceptions must be documented.
When not to use
A quick sketch for a non-technical audience (use a swimlane flowchart).
Software object behaviour (use a UML activity or state machine diagram).
5. As Diagrams-as-Code
Mermaid has no BPMN renderer, so the usual diagrams-as-code approach is a Mermaid flowchart with subgraphs as lanes. For an executable model, export BPMN 2.0 XML from bpmn.io or Camunda Modeler instead.
flowchart LR
subgraph Sales
S((Order received)) --> CS[Check stock] --> G{In stock?}
G -- No --> N[Notify customer] --> E1(((Order rejected)))
end
subgraph Warehouse
P[Pick and pack]
SH[Ship order] --> E2(((Order shipped)))
end
subgraph Finance
C[Charge card]
end
G -- Yes --> P
G -- Yes --> C
P --> SH
C --> SH
The flowchart loses the gateway types and message flows; keep the BPMN drawing as the reference and the Mermaid as a readable summary.