What is BPMN?
Business Process Model and Notation: a process language precise enough for an engine to run and plain enough for the person who does the work to correct it. That second half is the hard part, and it is why BPMN exists.
10 min readBPMN 2.01 of 3
01What it is
BPMN is a notation for business processes - the order things happen in, who does them, and what makes them branch. It is an OMG standard, the same body that owns UML, and version 2.0 is the one everything means when it says BPMN.
Its design goal is unusual and worth stating plainly: it is meant to be readable by the business and executable by an engine. The same diagram that an operations manager corrects in a workshop can, with enough detail filled in, be deployed to a process engine and run. No other process notation seriously attempts both.
That dual purpose explains the size of the symbol set. BPMN has around a hundred symbols, which sounds alarming and is not: they are five families with variations, and a diagram using twenty of them covers almost every process anyone draws.
02The five families
| Element | Notation | What it means |
|---|---|---|
| Events | circles | Something happens. Border weight says when: thin starts the process, double happens during it, thick ends it. An interior glyph says what kind - a message, a timer, an error. |
| Activities | rounded rectangles | Work being done. A task is atomic; a sub-process contains a process of its own and can be drawn collapsed with a +. |
| Gateways | rhombi | Where paths split or join. The interior marker says which rule - exclusive, parallel, inclusive, event-based. |
| Connecting objects | Sequence flow (solid, filled head) inside a pool; message flow (dashed, open circle and hollow head) between pools; association (dotted) to artifacts. | |
| Swimlanes | pools and lanes | Who is responsible. A pool is a participant, a lane is a subdivision within one. |
Artifacts - data objects, groups, text annotations - are a sixth family, and they carry no execution meaning at all. They are notes.
The family a symbol belongs to is always visible from its outline: circle, rounded rectangle, rhombus. The variation within a family is always an interior marker or a border weight. That regularity is what makes a hundred symbols learnable - you are learning five shapes and a set of decorations, not a hundred pictures.
03Sequence flow is not message flow
This is the rule that separates a BPMN diagram from a flowchart with round corners: a sequence flow may never cross a pool boundary. A pool is an independent participant with its own process, and you do not get to say what order another organisation does its work in. All you can say is that you sent them something, which is a message flow.
| Element | Notation | What it means |
|---|---|---|
| Sequence flow | "Then this happens." Solid line, filled arrowhead. Stays inside one pool, always. | |
| Message flow | "This is sent to them." Dashed line, open circle at the sender, hollow arrowhead at the receiver. Crosses pools, always. | |
| Association | "This note is about that." Dotted line. Connects artifacts to flow objects and means nothing to an engine. | |
| Default flow | a tick on the line's tail | The branch taken when no other condition on the gateway holds. Exactly one per branching gateway. |
04Pools, lanes, and who is responsible
Inside one pool, lanessubdivide the work by role, department, or system. They carry no execution semantics whatsoever - an engine ignores them completely - and they are still the most valuable thing on many diagrams, because "who does this step" is the question a process workshop actually argues about.
A useful discipline: every lane crossing is a hand-off, and every hand-off is a place work waits. Counting the sequence flows that cross a lane boundary gives you a first-pass list of where the process is slow, before anybody measures anything.
05Three levels of BPMN
Almost every argument about "how much BPMN is too much" dissolves once you name which of these three you are doing.
| Element | Notation | What it means |
|---|---|---|
| Descriptive | ~10 symbols | For humans. Start, end, tasks, exclusive and parallel gateways, pools, lanes, message flows. What a workshop produces and what most published process documentation should be. |
| Analytic | ~30 symbols | Adds the event types, boundary events, sub-processes and event-based gateways. Precise enough to simulate and to reason about exceptions. |
| Executable | the full set, plus data | Every branch condition, every data mapping, every service binding filled in. Deployed to an engine. The diagram is now source code, and should be reviewed like it. |
The mistake is not picking the wrong level - it is mixing them in one diagram. A descriptive model with three fully specified error boundary events and eleven bare tasks pleases nobody: too detailed to skim, too incomplete to run.
06BPMN, activity diagram, or ArchiMate?
Reach for it when
- The process crosses organisations and the hand-offs are the subject
- Business people have to read, correct, and sign off the diagram
- The model may eventually be executed by a process engine
- Exceptions, timers and compensating actions matter as much as the happy path
Reach for something else when
- You are describing an algorithm inside one system - use an activity diagram
- You need the landscape rather than the process - use ArchiMate
- The audience is developers and the subject is a call sequence - use a sequence diagram
- It is four boxes in a line and a flowchart would do
A UML activity diagram covers similar ground and is better inside a system: it has richer control-flow constructs and sits naturally beside the other UML diagrams describing the same software. BPMN wins the moment more than one organisation is involved, because pools and message flows have no equivalent in UML that a business audience will read.
ArchiMatecan draw a business process too, and should - at one box per process, in a landscape view. The moment you want to know what happens when the payment fails, that is BPMN's question, not ArchiMate's.
07Common mistakes
- Sequence flow across a pool boundary.The single most common error, and it means the diagram claims authority over someone else's process.
- No end event. Every path must end at one. A dangling task leaves a process token alive forever, which is a real bug once the model is executed and a real ambiguity before that.
- Decisions drawn inside tasks.A task that "checks and routes" hides the branch. Put a gateway after it.
- Gateways that both branch and merge. Legal, unreadable. Use one to split and a second to join.
- Lanes named after people. Name the role. People change jobs and the diagram should not need editing when they do.
In one line each
- 01Five families: events, activities, gateways, connecting objects, swimlanes.
- 02Outline says the family; interior marker and border weight say the variation.
- 03Sequence flow never crosses a pool; message flow only crosses pools.
- 04A pool you do not control belongs empty - a black box with messages touching it.
- 05Pick descriptive, analytic or executable and keep one diagram at one level.
- 06Every path ends at an end event, and gateways either split or join, never both.
Related reading