BPMN (Business Process Model and Notation) is the standard language for drawing business processes: a set of symbols that business and IT read the same way and that, in version 2.0, an engine can execute. Knowing how to read and write a BPMN diagram is the core skill of anyone who works with processes — and mastering gateways is what separates a pretty drawing from a process that actually works.
This guide walks through the BPMN symbols grouped into families, with an SVG of each one, explains the four gateways and the classic mistake that causes a deadlock, and ends with a complete BPMN diagram for invoice approval. It is the practical companion to our guide What is BPM?.
BPMN stands for Business Process Model and Notation. It is the international standard for graphically representing how a process works, maintained by the Object Management Group (OMG) and published as the ISO/IEC 19510 standard. Its goal is for the same diagram to be understood by three audiences that usually speak different languages: the business analyst who knows the process, the manager who approves it and the technical team that implements it.
The big difference between BPMN and a simple flowchart is its precise semantics. In a flowchart, a diamond means "a decision" and every author draws it their own way. In BPMN, a diamond with an X inside is an exclusive gateway with behaviour defined down to the last detail, distinct from a diamond with a + sign (parallel). That precision is what makes a BPMN 2.0 diagram executable: a process engine interprets it directly and turns it into a real application, with no one having to "translate" it into code and lose nuances along the way.
It helps to place BPMN within the wider discipline it serves. BPMN is the notation used in the modeling phase of the BPM lifecycle; if you want the full picture — what process management is, how it differs from a workflow or RPA and how it is rolled out — start with the pillar guide What is BPM?.
In one sentence: BPMN is to processes what the musical staff is to music. A common language anyone can read and a machine can execute. This guide teaches you to read it and to write it well.
BPMN 2.0 defines dozens of symbols, but you don't need to memorize them all. Four families cover the vast majority of business diagrams: events, activities, gateways and sequence flows. Around them, two organizing elements — lanes (responsibility) and artifacts (annotations and data objects) — complete the picture.
Circles. Something that happens: it starts, interrupts or ends the process.
Rounded rectangles. The work: tasks and subprocesses.
Diamonds. Decisions: the flow branches or synchronizes.
Arrows. The order: they connect the elements in sequence.
A pool represents a participant (an organization or a system); inside it, the lanes (swimlanes) divide the work by role or department. They place each activity under a clear owner. We cover this in detail in section 6.
They don't alter the flow, they document it: data objects (a document going into or out of a task), text annotations (notes for the reader) and groups (boxes that visually cluster). Useful so the diagram reads on its own.
An event is something that happens during the process. It is always drawn as a circle, and the thickness of the border indicates its position in the flow: the start event has a thin border, the intermediate one is a double circle and the end one has a thick border. That rule alone already lets you read where a process comes in and goes out at a glance.
In addition, an icon inside the circle indicates the type of event: an envelope is a message event (something arrives or is sent), a clock is a timer (a deadline expires), a bolt is an error and a triangle is a signal (a broadcast that several processes can listen to at once).
The process starts when something arrives from outside: an email, a submitted web form, an invoice received. It is the most common trigger in business processes.
It makes the flow wait ("wait 3 days") or, attached to the boundary of a task, interrupts it if the deadline expires. It is the basis of automatic SLA escalations.
It catches a failure in a task or subprocess and diverts the flow down an error-handling branch, without breaking execution.
It closes a path of the process. A diagram can have several end events (approved, rejected, cancelled): that is not an error, it is good practice to distinguish outcomes.
An activity is the work that gets done, and it is drawn as a rounded-corner rectangle. What distinguishes one task type from another is a small icon in the top-left corner: a person for a user task, gears for a service task, a hand for a manual task, a scroll for a script task and a table for a business rule task.
When an activity contains another process inside it, it is a subprocess (with a + sign on the bottom edge, indicating it can be expanded) or a call activity (thick border) that invokes a reusable process defined separately. And the markers at the base of the task indicate repetition: a loop (↻) or three bars for multi-instance (the same task for several items at once, e.g. "request a quote from 3 suppliers").
A detail that matters for execution: the task type is not decorative. In a BPMN engine, a user task creates an entry in a person's inbox; a service task triggers a call to a system or API; a business rule task evaluates a decision table. That is why modeling each task's type correctly is what makes the diagram directly executable. A service task can be resolved by code, by an RPA bot or by a governed AI agent — the diagram does not change.
Gateways are the heart of a process's logic and the part that raises the most questions. They are always drawn as a diamond, and an inner symbol defines their behaviour. There are four you need to master. The mental rule: a diverging gateway opens paths and a converging one brings them back together; using the wrong type when joining them is the number one cause of processes that deadlock.
The flow takes a single path, the first whose condition is true. It is the "if/else" of the process. Example: "is the amount over €5,000?" → Yes goes to director approval; No, it is posted directly. Only one of the two branches runs.
It activates all paths simultaneously, with no conditions. Example: when hiring someone, in parallel the IT equipment is prepared, they are registered in payroll and an access card is requested. The parallel convergence waits for all of them to finish before continuing.
It activates every path whose condition is met, from one to all. Example: a claim may require, depending on the case, legal review, technical review or both. The inclusive convergence waits only for the branches that actually fired.
The path is not decided by a data condition, but by which event happens first. Example: after sending a quote, the process waits: if the customer's acceptance arrives, it goes to billing; if the 15-day deadline (timer) expires, it goes to sales follow-up.
The most frequent error when modeling BPMN: opening the flow with an exclusive gateway (where only one branch fires) and then trying to close it with a parallel gateway for convergence. The parallel one waits for all branches to arrive — but since the exclusive only activated one, the others never arrive. The process waits forever: that is a deadlock.
The rule to avoid it: close with the same type you opened with. What diverged in an exclusive comes back together in an exclusive; parallel with parallel; inclusive with inclusive. Matching the opening with the closing eliminates the vast majority of deadlocks.
A BPMN diagram shows not only what happens, but who does it. That is what lanes (swimlanes) are for. Picture a swimming pool seen from above: the large rectangle is the pool (the whole participant, e.g. "Our company") and the horizontal stripes inside it are the lanes, one per role or department: Finance, HR, the system. Each task is drawn in the lane of the owner that executes it — so, reading vertically, you know whose each step is.
The key distinction is when to use a lane and when a separate pool:
When all participants belong to the same organization and share the process. Tasks are connected with sequence flows (solid arrows) that cross from one lane to another. Example: Finance and the ERP system in the invoice process.
When another organization is involved (a customer, a supplier, a public administration) whose internal process you neither control nor see. Pools are not connected with sequence flows, but with message flows (dashed arrows): they only exchange communications.
This rule avoids a common error: putting the customer as just another lane inside your pool. You do not orchestrate the customer's internal tasks — you only send and receive messages from them. Modeling it as a separate pool makes the boundary of responsibility clear and makes the diagram honest about what you actually control.
Let's put it all together in a real diagram. We model the approval of an invoice with a pool of two lanes — Finance (the people) and System (the automatic steps) — a message start event, an OCR service task, an exclusive gateway that decides based on the amount, a user approval task, the posting to the ERP and an end event.
Read it following the arrows: the invoice arrives and starts the process in the System lane; the OCR service task extracts amount, supplier and due date; the exclusive gateway looks at the amount. Those under €5,000 don't need a person and go straight to the ERP; those above go up to the Finance lane, where a person approves before the system records them. A single end event marks "posted".
Notice what the diagram makes explicit without a single line of prose: which steps are automatic and which human (the lanes), where the decision is and on what criterion (the gateway and its label), and when a person steps in (only above the threshold). That is the power of BPMN: it documents, communicates and — in BPMN 2.0 — executes, all with the same drawing. This is exactly the kind of process you'll find ready to activate in the catalog of BPM templates.
Here is the difference that changed the market. In the world of traditional flowcharts, the drawing was documentation: someone approved it, and then a team "translated" it into code. In that translation nuances were lost, differences were introduced and, six months later, the diagram and reality no longer matched.
With BPMN 2.0 on a process engine, there is no translation: the diagram is the program. The engine reads the model's XML (BPMN 2.0 defines a standard interchange format) and executes it as is. When the flow reaches a user task, the engine creates the entry in the person's inbox; on a service task, it calls the system; on a gateway, it evaluates the condition and chooses the branch. What the business validated is, literally, what runs in production.
On a low-code BPM platform this goes one step further: beyond the diagram, you design the forms, the rules and the integrations visually, without programming. The modeling and execution phases of the BPM lifecycle collapse into one. That is why the first productive process is measured in weeks, not months.
If you want to see how an executable BPMN process is built end to end, take a look at the Dokuflex low-code BPM platform; and for the full context of the discipline, the guide What is BPM?.
A technically correct BPMN diagram can still be unreadable. These simple conventions make the difference between a model that explains itself and one that needs explaining:
"Approve invoice", "Record in ERP", "Notify customer". Not "Invoice" or "Management": a task is an action. Events, by contrast, are named as a noun or state ("Invoice received", "Contract signed").
Draw the main flow in a straight horizontal line and leave exceptions and rejections branching up or down. The reader should be able to follow the normal case effortlessly and see the deviations as branches.
Crossing arrows are the visual sign of a messy diagram. Rearrange the position of the tasks until the flows don't overlap; you almost always can.
If a process grows too large, it stops being readable. Encapsulate blocks in subprocesses that expand: the top-level diagram tells the story, and each subprocess provides the detail to whoever needs it.
What an exclusive opens, an exclusive closes; parallel with parallel. It is the rule that avoids the deadlocks from section 5. And always label the branches of an exclusive (Yes/No, <5,000/>5,000).
A process evolves. Save versions of the model and, in the engine, keep the old version running alongside for cases in progress and the new one for those just starting. Changing the diagram should not break what is already underway.
And one deeper mistake beyond notation: don't model the process you wish you had, model the one you have — including its real exceptions — and then improve it. An idealized diagram that ignores the hard cases breaks on its first day in production.
BPMN stands for Business Process Model and Notation. It is the international standard, maintained by the Object Management Group (OMG) and published as ISO/IEC 19510, that defines a graphical language for drawing processes in a way anyone can understand and, in BPMN 2.0, an engine can execute.
No. A classic flowchart is informal: every author uses the symbols their own way and it is not executable. BPMN 2.0 is a standard with precise semantics: each symbol has a defined meaning (message or timer events, exclusive or parallel gateways, lanes per owner) and a BPM engine can interpret the diagram and put it into production without reinterpreting it.
The inclusive gateway (diamond with a circle inside, the O symbol). It activates every path whose condition is true, from one to all at the same time. If only one condition can be true, use the exclusive (X); if you always want to launch all paths in parallel, with no condition, use the parallel (+). Remember to close an inclusive divergence with another inclusive gateway for convergence so it synchronizes correctly.
To draw it, any editor that supports the standard will do (including free editors based on bpmn.io). But the value of BPMN 2.0 is that the diagram is executable: on a low-code BPM platform the very diagram you validate with the business becomes the real application, with forms, rules and integrations, without redrawing it in another tool.
Yes. A task in a BPMN process can be performed by a person, a service, an RPA bot or an AI agent. Modeling the AI step as a service task within the diagram keeps traceability: the following gateway decides based on the result or the confidence level, and the flow escalates to a user task when the AI does not reach the threshold (human-in-the-loop).
Although BPMN 2.0 defines dozens of symbols, four groups cover 90% of real diagrams: events (start, intermediate, end), activities (tasks and subprocesses), gateways (exclusive, parallel, inclusive and event-based) and sequence flows, organized into lanes. That subset models almost every business process.
Bring the process you already have drawn — invoices, time off, onboarding — and we'll show you the same BPMN diagram running on Dokuflex in a 30-minute demo. No commitment, and with your case, not a lab one.