What is BPMN 2.0?
Business Process Model and Notation (BPMN) 2.0 is the globally accepted ISO standard (ISO/IEC 19510) for graphically representing business processes. Maintained by the Object Management Group (OMG), it provides a standardized language that bridges the gap between business process design and technical process execution.
Unlike proprietary flowchart notations, BPMN 2.0 is tool-agnostic — a model created in one BPMN-compliant tool can be read, shared, and executed in any other. This makes it the lingua franca for enterprise process documentation, automation, and governance.
BPMN 2.0 Quick Facts
The 5 Core Element Categories
Every BPMN 2.0 diagram is built from elements that belong to one of five categories. Understanding each category is the foundation of BPMN literacy.
Triggers and outcomes that initiate, modify, or terminate process flow.
Work performed within a process — by people, systems, or both.
Control divergence and convergence of sequence flows — the decision points.
Lines that link elements and define the order of execution.
Containers that organize processes by participant, role, or department.
Element Reference
Every BPMN 2.0 element with its symbol, definition, and practical guidance. Browse by category using the tabs below.
7 elements in this category
None Start Event
Start EventMarks where a process instance begins. Every process must have at least one start event.
Use when: Triggering a new process flow with no specific trigger type.
Message Start Event
Start Event (Message)Process starts when a message is received from another participant or system.
Use when: Processes initiated by emails, API calls, or inter-process messages.
Timer Start Event
Start Event (Timer)Process starts at a specific time, date, or on a recurring schedule.
Use when: Batch jobs, scheduled reports, periodic compliance checks.
Intermediate Event
Intermediate EventOccurs between the start and end of a process. Can represent waiting periods or triggers.
Use when: Delays, wait states, or mid-process triggers within a flow.
None End Event
End EventMarks the end of a process path. All active paths must reach an end event to complete the process.
Use when: Standard process completion. Use multiple end events for different outcomes.
Error End Event
End Event (Error)Ends the process path by throwing an error, which can be caught by an error boundary event.
Use when: Fatal failures requiring error handling or escalation.
Message End Event
End Event (Message)Sends a message to another participant or pool when the process path ends.
Use when: Notifying external systems or participants upon process completion.
Complete Worked Example
An annotated Invoice Approval process demonstrating events, user tasks, an exclusive gateway, and swimlanes working together. Numbers correspond to the legend below.
Gateway Decision Guide
Choosing the wrong gateway is the most common BPMN mistake. Use this guide to pick the right one every time.
Exclusive (XOR) Gateway
Exactly ONE path is taken. Conditions on outgoing flows must be mutually exclusive and collectively exhaustive.
- →Invoice amount ≤ $1K → Auto-approve
- →Invoice amount > $1K → Manual review
Leaving paths without conditions — always label each outgoing flow.
Parallel (AND) Gateway
ALL outgoing paths fire simultaneously. A matching AND gateway waits for all branches to complete before continuing.
- →Legal review starts in parallel with...
- →...Finance review — both must complete.
Forgetting the merging AND gateway — flows will diverge and never reconverge.
Inclusive (OR) Gateway
ONE OR MORE paths are taken based on conditions. More flexible than XOR — multiple paths can be active.
- →Send email notification
- →Send SMS (if mobile on file)
- →Log to system (always)
Using OR when exactly one path is always taken — use XOR instead for clarity.
Event-Based Gateway
Routes flow based on which event occurs first. Only ONE path fires — whichever event triggers first wins.
- →Approval received → Continue process
- →48-hour timer expires → Escalate
Using a regular XOR gateway when the decision depends on an external event rather than data.
Gateway Quick-Pick
| Question | Answer | Use gateway |
|---|---|---|
| Is the decision data-driven? | Yes, exactly one path | Exclusive (XOR) |
| Do multiple paths need to run concurrently? | Yes, all of them | Parallel (AND) |
| Can more than one path be valid? | Yes, one or more | Inclusive (OR) |
| Does the outcome depend on which event fires first? | Yes, race condition | Event-Based |
| Is there no condition — all paths always fire? | Yes, always | Parallel (AND) |
BPMN 2.0 Best Practices
Rules followed by professional process architects to keep diagrams readable, correct, and maintainable.
One Start, Clear Ends
Every process must have at least one start event. End events should explicitly label each outcome (Approved, Rejected, Escalated) — never leave flows dangling.
Label All Gateway Paths
Every outgoing sequence flow from a gateway must be labeled with its condition. For XOR gateways, mark the default path with a slash (/) marker.
Pools for Participants, Lanes for Roles
Use separate pools for distinct organizations or systems. Use lanes within a pool to divide work by role or department. Never put sequence flows between pools — use message flows.
Left-to-Right, Top-to-Bottom
Process flow should generally run left-to-right. Exception flows (rejections, errors) conventionally route back or downward. Consistent direction prevents cognitive load.
One Process Level of Detail
Each diagram should represent one level of abstraction. If an activity has its own complex flow, make it a collapsed sub-process — don't inline 20 tasks in a single diagram.
Use Events for Loops, Not Arrows
Looping back should use an intermediate event (e.g. 'Revision Required') to make the loop trigger explicit. Avoid raw arrows pointing backwards — they obscure the trigger.
Name Activities as Verb + Noun
Activity names should follow the pattern: action verb + object. 'Review Invoice', not 'Invoice Review'. 'Send Notification', not 'Notification'. Consistent naming aids automation.
Model SLAs with Timer Events
Use intermediate timer events to make SLAs explicit in the model. A boundary timer on a task with an escalation path makes compliance measurable and automated.
Validate Against BPMN 2.0 Spec
Syntactically correct diagrams are not always semantically valid. Run BPMN validation to catch missing markers, incorrect event types, and flow dead-ends before publishing.
BPMN 2.0 vs. Traditional Flowcharts
Why organizations upgrading from Visio flowcharts to BPMN 2.0 see immediate clarity gains.
| Dimension | Traditional Flowchart | BPMN 2.0 |
|---|---|---|
| Standard | Informal, tool-specific | ISO/IEC 19510 — globally standardized |
| Participants | Implied or via ad-hoc shapes | Explicitly modeled with Pools and Lanes |
| Events | Start/end boxes only | 9+ event types with semantic meaning |
| Gateways | Diamond with text labels | 4 distinct gateway types with defined semantics |
| Parallel flows | Difficult to represent | Native with Parallel (AND) Gateways |
| Error handling | Not standardized | Error/escalation events and boundary events |
| Executable? | No — documentation only | Yes — BPMN XML can drive workflow engines |
| Tool portability | Proprietary formats | BPMN 2.0 XML exports to any compliant tool |
| Automation readiness | Requires re-design | Model is execution-ready as-is |
