BPMN Business Process Diagrams

BPMN (Business Process Model and Notation) is the standard way to draw a business process: who does what, in which order, and where decisions and hand-offs happen. It is maintained by the Object Management Group (OMG); BPMN 2.0 is also published as ISO/IEC 19510. Business analysts read it to understand and improve processes, and engineers read it because workflow engines can execute it directly.

1. The Notation

BPMN has a large specification, but four families of symbols cover almost every diagram you will draw:

Events are circles: something that happens. A thin border is a start, a thick border is an end, and a double border is an intermediate event in the middle of the flow. An icon inside says what kind: a clock for a timer, an envelope for a message.
Activities are rounded rectangles: work that someone or something does. A task is one step; a sub-process with a [+] marker hides more detail.
Gateways are diamonds where the path splits or merges. X is exclusive (take exactly one path), + is parallel (take all paths, then wait for all), O is inclusive (take one or more).
Flows and swimlanes: solid arrows are sequence flow inside one process; dashed arrows are messages between separate participants. A pool is a participant (a company, a system); lanes divide a pool by role or department.

2. Example 1: Online Order Fulfilment

Walk through it from the left. The process starts with a message start event: an order arrives. The shop checks payment, then an exclusive gateway asks "Paid?". If not, the order is cancelled and the process ends. If yes, a parallel gateway splits the flow: the shop sends the invoice while the warehouse picks and packs, at the same time. The second parallel gateway is a join: shipping only starts once both branches are done. The two lanes make responsibility obvious: anything in the Warehouse lane is that team's job.

3. Example 2: IT Support Ticket

A ticket is raised and triaged. If it is a known issue, the support agent applies the documented fix; otherwise they investigate. The small clock on the edge of "Investigate" is a timer boundary event: if investigation runs longer than four hours, the flow leaves the task and escalates to second-line support. All paths meet at an exclusive merge, the user confirms the fix, and the ticket closes. If the user says it is not fixed, the flow loops back. Boundary events are what make BPMN good at describing deadlines and exceptions.

4. Pros and Cons

Pros

An international standard, so diagrams mean the same thing across teams and tools.
Readable by business people and precise enough for engineers.
Swimlanes make ownership and hand-offs between teams explicit.
Handles real-world detail: timers, messages, errors, compensation, parallel work.
BPMN 2.0 XML can be executed by workflow engines (Camunda, Flowable, jBPM), so the diagram is the running process.
Good tool support, including free editors such as bpmn.io.

Cons

The full specification is large; diagrams using rare symbols confuse readers.
Large processes become wall-sized; you need sub-processes and discipline.
Not designed for data structures, system architecture or software internals.
Executable BPMN needs extra technical attributes that business users do not see.
Easy to draw the happy path only and forget exceptions.
Diagram files from different tools do not always round-trip cleanly.

5. When to Use and When Not To

Use BPMN when you are documenting or redesigning a process that crosses roles or departments, agreeing a workflow between business and IT, preparing to automate a process in a workflow engine, or proving to auditors how an approval process actually runs.

Do not use BPMN for the internal logic of one program (an activity diagram or flowchart is lighter), for message order between objects or services (use a sequence diagram), for how data moves between stores (use a data flow diagram), or for the states one object goes through (use a state machine diagram).

6. Diagrams as Code

BPMN's native format is BPMN 2.0 XML. Editors such as bpmn.io (bpmn-js) and Camunda Modeler render it and add the layout information; engines like Camunda execute it. Here is the order process (layout section omitted):

<!-- BPMN 2.0 XML: the interchange format read by Camunda, bpmn.io, Signavio -->
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  id="defs" targetNamespace="http://example.com/order">
  <bpmn:process id="order" isExecutable="true">
    <bpmn:startEvent id="received" name="Order received"/>
    <bpmn:task id="check" name="Check payment"/>
    <bpmn:exclusiveGateway id="paid" name="Paid?"/>
    <bpmn:task id="cancel" name="Cancel order"/>
    <bpmn:parallelGateway id="split"/>
    <bpmn:task id="invoice" name="Send invoice"/>
    <bpmn:task id="pick" name="Pick and pack"/>
    <bpmn:parallelGateway id="join"/>
    <bpmn:task id="ship" name="Ship parcel"/>
    <bpmn:endEvent id="delivered" name="Delivered"/>
    <bpmn:endEvent id="cancelled" name="Cancelled"/>
    <bpmn:sequenceFlow id="f1" sourceRef="received" targetRef="check"/>
    <bpmn:sequenceFlow id="f2" sourceRef="check" targetRef="paid"/>
    <bpmn:sequenceFlow id="f3" sourceRef="paid" targetRef="split" name="yes"/>
    <bpmn:sequenceFlow id="f4" sourceRef="paid" targetRef="cancel" name="no"/>
    <bpmn:sequenceFlow id="f5" sourceRef="cancel" targetRef="cancelled"/>
    <bpmn:sequenceFlow id="f6" sourceRef="split" targetRef="invoice"/>
    <bpmn:sequenceFlow id="f7" sourceRef="split" targetRef="pick"/>
    <bpmn:sequenceFlow id="f8" sourceRef="invoice" targetRef="join"/>
    <bpmn:sequenceFlow id="f9" sourceRef="pick" targetRef="join"/>
    <bpmn:sequenceFlow id="f10" sourceRef="join" targetRef="ship"/>
    <bpmn:sequenceFlow id="f11" sourceRef="ship" targetRef="delivered"/>
  </bpmn:process>
</bpmn:definitions>

Mermaid has no BPMN diagram type, but a flowchart with subgraphs is a common lightweight approximation for documentation that renders in GitHub, GitLab and many wikis. It loses the precise event and gateway semantics:

flowchart LR
  %% Mermaid has no native BPMN; this flowchart mimics example 1.
  subgraph Shop
    S((Order received)) --> C[Check payment] --> G{Paid?}
    G -- no --> X[Cancel order] --> E1(((Cancelled)))
    G -- yes --> P1{{AND split}}
    P1 --> I[Send invoice]
  end
  subgraph Warehouse
    P1 --> K[Pick and pack]
    I --> J{{AND join}}
    K --> J --> SH[Ship parcel] --> E2(((Delivered)))
  end

UML Activity Diagrams — the closest UML relative; better for software logic.
Sequence Diagrams
Use Case Diagrams — what the actors want, before how.
State Machine Diagrams
Interaction Overview Diagrams
Data Flow Diagrams
UML diagrams overview