Pillar guide
BPMN, explained with the diagrams you will actually draw.
BPMN has a reputation problem: a standard with hundreds of pages, tutorials that catalogue fifty symbols you will never use, and diagrams in the wild that look like circuit boards. Underneath that, there is a small, sharp core that lets you draw a process once and have everyone read it the same way. This guide covers that core: the symbols worth knowing, gateways and events in depth, a full worked example, and the modelling mistakes that make diagrams unreadable.
Written by Israel Bankole, founder of Backlog.cloud. Last updated 9 August 2026.
The standard
What BPMN is and why the standard matters
Business Process Model and Notation is a standardised visual language for describing business processes: the steps, the decisions, the handovers between people and systems, and the events that start, interrupt or end the work. It is maintained by the Object Management Group, and the current widely adopted release is BPMN 2.0, published as an open specification by OMG.
The word doing the heavy lifting is "standard". When you draw a diamond with an X in it, every BPMN-literate reader, and every conforming tool, knows it means exactly one outgoing path is taken. When your homemade flowchart uses a diamond, it means whatever you meant that afternoon. The 2.0 release went further than notation: it defined execution semantics and an XML interchange format, so the same model can be read by an analyst, validated by a tool, and in some environments executed directly by a process engine.
You do not need the whole specification. It is a large document that defines far more vocabulary than everyday modelling uses. What you need is the working subset in this guide: three flow object families (activities, gateways, events), the connections between them, and pools and lanes to show who does what. That subset covers the overwhelming majority of process diagrams drawn in real organisations.
Vocabulary
The core symbol set in plain language
Every BPMN diagram is built from things that happen, decisions between them, events that trigger or interrupt them, arrows that order them, and containers that say who is responsible. That is the whole grammar.
Rounded rectangle
Tasks and activities
A task is a single unit of work: "Check claim", "Send invoice". BPMN distinguishes who performs it. A user task is a human working through a system. A manual task is a human working outside any system. A service task is software acting alone. That distinction sounds fussy until you are hunting for automation candidates, at which point it is the most useful information on the page. A sub-process is a task that expands into its own diagram, which is how you keep any one diagram readable.
Solid arrow
Sequence flows
A sequence flow is the solid arrow saying "this happens, then that". It carries order, not data. Flows leaving an exclusive gateway carry conditions ("over 500", "500 or under"), and unlabelled conditional flows are the most common readability failure in real diagrams. There is a second arrow, the dashed message flow, which crosses between pools. Solid inside a pool, dashed between pools. Mixing them up is the fastest way to signal a diagram was not drawn carefully.
Circles
Events
Events are things that happen to the process rather than work the process does. A thin circle starts a process, a thick circle ends it, a double circle sits in the middle, pausing the flow or catching interruptions. The icon inside the circle names the trigger: an envelope for a message, a clock for a timer, a lightning bolt for an error. Events get their own section below, because they are where BPMN earns its keep.
Containers
Pools and lanes
A pool is an independent participant: your organisation, the customer, a payment provider. A lane divides a pool by role or team: claims handler, manager, finance. Placing a task in a lane is an accountability statement, and the vertical drops where flow crosses lanes are the handovers, which is where queues form and days vanish. A diagram with sensible lanes answers "who owns this step?" at a glance.
Routing
Gateways in depth
Gateways are the diamonds, and they route the flow: splitting it down alternative or concurrent paths, and merging it back. Two rules save most beginners. A gateway makes no decision itself, it only routes based on conditions that already exist, so name it as a question ("Claim complete?") and label every outgoing flow. And whatever splits the flow should usually be what joins it: a parallel split joined by an exclusive merge is a classic bug that fires the rest of the process once per branch.
Four gateway types cover practically everything.
| Gateway | Marker | Semantics | Typical use | Common trap |
|---|---|---|---|---|
| Exclusive (XOR) | X marker, or blank diamond | Exactly one outgoing path is taken, based on a condition. | Approve or reject. Over the limit or under it. The everyday decision. | Conditions that are not mutually exclusive, so two paths could both be true. |
| Parallel (AND) | Plus marker | All outgoing paths run concurrently. The joining gateway waits for every one. | Reference check and credit check can happen at the same time. | Forgetting the join, or joining with an exclusive gateway so the process fires twice. |
| Inclusive (OR) | Circle marker | One or more paths are taken, each governed by its own condition. | Notify finance if over budget, notify legal if a contract changes. Both can apply. | Hard to reason about at the join. If exclusive or parallel can model it, prefer them. |
| Event-based | Pentagon inside double circle | The path taken depends on which event happens first, not on data. | Wait for the customer reply, or time out after 5 working days, whichever comes first. | Using an exclusive gateway with conditions to fake it. Waiting on events is what this one is for. |
When to reach for which: default to exclusive, because most business routing is a single decision on data. Use parallel when work genuinely can proceed at the same time and you want the diagram to say so, since sequencing independent work is one of the biggest hidden costs a process map can expose. Use event-based when the process is waiting on the outside world: a reply, a payment, a deadline. Treat inclusive as a specialist tool you justify each time, not a habit.
Triggers
Events: start, intermediate, end
Events have two dimensions: position (does it start the process, sit in the middle, or end it?) and trigger (what kind of thing happened?). Position is drawn with the circle border: thin for start, double for intermediate, thick for end. The trigger is the icon inside. Read the table row by row and the system snaps into focus.
| Trigger | As a start event | As an intermediate event | As an end event |
|---|---|---|---|
| None (blank) | The process begins, cause unspecified | A milestone marker within the flow | The process finishes normally |
| Message | A message arrives and starts the process (an order, a claim, an email) | The process sends a message, or pauses to wait for one | The process ends by sending a message |
| Timer | The process starts on a schedule (every Monday, month end) | The process waits for a duration or a date before continuing | Not used. A timer cannot end a process |
| Error | Only on an event sub-process, reacting to an error | Attached to an activity boundary, it catches a failure and routes to handling | The process ends by throwing an error a caller can catch |
The workhorse pattern is the boundary event: an intermediate event attached to the edge of a task. A timer on the boundary of "Manager reviews claim" means "if this takes more than 5 days, do something else". An error on the boundary of "Take payment" means "if the charge fails, route to the retry path". Boundary events are how BPMN models the unhappy paths, and the unhappy paths are usually why you are mapping the process at all. A process model with no timer and no error anywhere is almost always a description of how the process is supposed to go, not how it goes.
The comparison
BPMN vs flowchart
A flowchart is a drawing. BPMN is a language. That is the whole difference, and it cuts both ways.
The flowchart's advantage is that nobody needs training to read one, which makes it the right choice for a five-box sketch in a slide deck. Its weakness appears the moment precision matters. What happens when two branches merge? Does that diamond mean "either" or "both"? Who performs step four? Where does the process go when the payment fails? A flowchart has no defined answers, so every reader supplies their own, and the disagreements surface at delivery time instead of design time.
BPMN answers all of those by definition. Merging semantics are specified per gateway type. Responsibility is structural, via lanes. Failure handling has first-class notation in boundary events. And because the standard defines an XML interchange format, the model is data: it can be validated for structural errors, opened in any conforming tool, and kept alongside the requirements it supports rather than dying in a slide deck.
The honest rule of thumb: if the diagram exists to give a rough shape to an idea, draw a flowchart in whatever tool is nearest. If the diagram is going to be used to agree how a process works, change how it works, or build software around it, the precision of BPMN pays for the half-day it takes to learn the core subset.
Worked example
Expenses approval, element by element
Here is a complete, realistic process walked through in the order you would model it. One pool (the company) with three lanes: employee, finance, manager. The narrative version first: an employee submits an expense claim, finance checks it, incomplete claims bounce back, claims over 500 need manager approval with a 5 day escalation, approved claims are paid automatically through payroll.
Now the same process as BPMN elements, with the modelling reasoning at each step.
- 1Start event (message)
Expense claim received
The process is triggered by something arriving from outside: an employee submits a claim. A message start event says so explicitly, which a plain circle would not.
- 2User task
Check claim for completeness
A person in the finance lane opens the claim and checks receipts are attached and categories are filled. User task, because a human does it through some interface.
- 3Exclusive gateway
Claim complete?
Two mutually exclusive paths: yes or no. The "no" path loops back to the employee with a task to fix the claim, then rejoins before the gateway. Label both outgoing flows, always.
- 4Exclusive gateway
Amount over 500?
Routing on data. At or under 500 goes straight to payment. Over 500 needs a manager. The condition lives on the flows, written so the two cannot both be true.
- 5User task
Manager reviews claim
This task sits in the manager lane, and the lane change is the point: the diagram shows the handover, which is where process time usually disappears.
- 6Event-based gateway + timer
Wait for decision, or 5 working days
What happens when the manager sits on it? An event-based gateway waits for whichever comes first: the decision, or a 5 working day timer that escalates to the department head. Most real processes need this and most diagrams omit it.
- 7Service task
Pay claim into payroll
A system does this without human involvement, so it is a service task. The distinction tells you where automation already exists and where people are doing machine work.
- 8End events (two)
Claim paid / Claim rejected
Two end states, two end events, each named. One generic "end" circle would hide the most important fact about the process: how it can finish.
Eight elements, three lanes, two decision points, one escalation, two named endings. Notice what the model surfaced that the narrative glossed over: the incomplete-claim loop, the stalled-manager escalation, and the fact that payment is already automated while checking is not. That gap between the told story and the modelled story is the reason to model at all.
Craft
Process mapping in practice
Knowing the notation is the easy half. The judgement calls are about what to model, at what depth, and which habits to avoid.
As-is before to-be
Model the current process first, workarounds and all, and validate it with the people who run it. Only then design the future state, as a separate diagram. Teams that skip to to-be design against an imagined current state, and their improvements quietly assume steps that do not exist and miss the workaround that is actually holding everything together. The two diagrams also serve different audiences: as-is is a diagnostic tool, to-be is a design contract.
Pick a granularity and hold it
A useful test for task size: one performer, one sitting, one outcome. "Review claim" passes. "Click the approve button" is keystroke-level noise, and "Handle claims" is a department, not a task. Mixed granularity is what makes diagrams feel wrong even when they are technically valid: one lane modelled per-click next to a lane modelled per-month. When detail genuinely matters, push it into a sub-process and keep each diagram at one consistent altitude, roughly 20 elements or fewer.
The mistakes that ruin diagrams
Gateway soup
Chains of diamonds with unlabelled flows, encoding what should be one business rule as four nested decisions. If three gateways sit in a row, the logic probably belongs in one decision task ("Determine approval route") followed by a single labelled gateway.
Lane proliferation
Eleven lanes, one per job title, most containing a single task, with the flow zigzagging between them until the handovers are unreadable. Lanes should reflect genuine changes of responsibility. Merge roles that act as one, and split a diagram that truly needs that many actors.
Happy-path fiction
No timers, no errors, one serene flow to a single end event. Real processes stall, fail and get rejected. If the diagram shows no way for that to happen, it is documentation of an aspiration. Ask "what happens when this step fails or takes too long?" at every task, and model the answers.
From talk to diagram
Process discovery from conversation
Almost every process model starts life as a conversation: a mapping workshop where someone narrates the process while a facilitator asks "and what happens if that gets rejected?" The traditional workflow is to scribble on a whiteboard during the session, photograph it, and spend an evening or two redrawing it as BPMN, hoping your notes captured which of the three exception paths went where.
That transcription step is now automatable. Record the process mapping workshop and the steps, decisions, handovers and exceptions people describe can be extracted into a validated process graph, laid out deterministically, and rendered as a BPMN 2.0 diagram you review and correct, with as-is and to-be handled as separate variants and the XML available on download.
What does not change is the facilitator's job. Extraction is faithful to what was said, and what was said is not always the real process. People narrate the official version, skip the workaround they no longer notice, and disagree with each other in ways only a follow-up question resolves. The machine gets you from conversation to reviewable draft in minutes instead of evenings. Deciding whether the draft is true remains analysis, and analysis is the part worth your hours anyway.
FAQ
BPMN, answered
- What does BPMN stand for and who maintains it?
- Business Process Model and Notation. It is an open standard maintained by the Object Management Group (OMG), with version 2.0 as the widely adopted release. Because the notation and its execution semantics are specified, a BPMN diagram means the same thing in every conforming tool, which is the entire advantage over ad hoc boxes and arrows.
- Do I need to know all of BPMN to use it?
- No, and almost nobody does. The full specification defines a large vocabulary, but a working subset covers the overwhelming majority of real diagrams: tasks, sequence flows, pools and lanes, exclusive and parallel gateways, and start, end, message, timer and error events. Learn that subset well and add the rest only when a diagram genuinely needs it.
- What is the difference between a pool and a lane?
- A pool is an independent participant in a process, such as your company, a customer, or a supplier. A lane is a subdivision inside a pool, usually a role or department. Sequence flows can only run inside a pool. Between pools you use message flows, because separate organisations coordinate by exchanging messages, not by sharing a process engine.
- When should I use an inclusive gateway instead of an exclusive one?
- Use exclusive when exactly one path can apply, and inclusive when several conditions can be true at once and every true path should run. In practice, inclusive gateways are rare in good models because their join behaviour is hard to reason about. If you can express the logic with an exclusive gateway or a parallel split, do that instead.
- Is BPMN just a fancier flowchart?
- They share the box-and-arrow surface, but a flowchart is freeform: symbols mean whatever the author intended that day. BPMN symbols have defined semantics, including how parallel branches join, what happens when a boundary error fires, and who is responsible for each step via lanes. That precision is what lets a BPMN model be validated, shared across teams, and even executed by a process engine.
- What is the difference between as-is and to-be process models?
- An as-is model documents the process as it actually runs today, workarounds included. A to-be model designs the future process. Keep them as separate diagrams. Blending them produces a model of a process that has never existed, which is useless for both diagnosis and design. Map as-is first, because improvement proposals built on an imagined current state fail on contact with reality.
- Can BPMN diagrams be generated automatically from a conversation?
- Yes, with a review step. When a process mapping workshop is recorded, the steps, decisions, handovers and exceptions people describe can be extracted into a validated process graph and rendered as a BPMN 2.0 diagram for a human to correct. The machine handles transcription into notation. Deciding whether the described process is the real one remains the facilitator’s job.
- What file format do BPMN diagrams use?
- The interchange format defined by the standard is BPMN 2.0 XML, which stores both the semantic model (the elements and their connections) and the diagram layout. Any conforming tool can open a valid BPMN 2.0 XML file, which keeps your process models portable rather than locked to one vendor’s canvas.
Keep going
Related workflows and resources
BPMN process models artefact
The process model Backlog.cloud generates: validated graph, SVG diagram, BPMN 2.0 XML.
Process mapping workshops
Running the session that produces the model, and what extraction listens for.
Requirements gathering guide
Elicitation techniques, question sets and traceability, in depth.
Transcript to BPMN
Have a recorded walkthrough already? Start the model from the transcript.
For business analysts
Where automated extraction fits in a working BA practice.
Meeting to backlog
The wider workflow: one conversation, twelve artefact types.
Map the process in the meeting, not the evening after
Backlog.cloud turns a recorded process mapping workshop into a BPMN 2.0 diagram you review and correct. 3 free generations, no card.