Business Process Model and Notation (BPMN) is the global standard for process notation, helping business and IT model workflows clearly. Explore its meaning, elements, comparisons, and uses in process design below.
Business Process Model and Notation (BPMN) is a standardized way to draw and understand how work gets done in an organization. Think of it as a universal diagramming language: simple enough for business users to follow, yet detailed enough for IT teams to build from.
Organizations use different methods to map or model processes—such as flowcharts, UML diagrams, swimlane diagrams, Gantt charts, value stream mapping (VSM), or SIPOC diagrams. Each has its strengths, but BPMN has become the most widely adopted because it combines clarity for people with precision for systems.
If you’re new to the discipline, start with the business process management definition and the BPM lifecycle to understand how BPMN supports the process design and optimization phases of continuous improvement.
Business Process Model and Notation (BPMN) is a standardized graphical language for documenting, analyzing, and improving business processes. It was developed and is maintained by the Object Management Group (OMG) to provide a shared framework for both business users and technical teams.
At its core, BPMN combines the simplicity of a flowchart with the rigor needed for automation and execution. It describes how work is performed across departments, systems, and roles, making it possible to design processes that are both understandable to non-technical stakeholders and precise enough to be implemented in IT systems.
Unlike simpler techniques such as flowcharts or swimlane diagrams, BPMN follows a globally recognized set of symbols and rules. This makes it ideal for organizations that need consistency across teams and geographies. It also differs from notations like UML (Unified Modeling Language), which are better suited for modeling system interactions rather than business workflows.
BPMN’s strength lies in its versatility: it can be used for process discovery, compliance documentation, optimization, and even as a foundation for automation projects. For many organizations, BPMN has become the default way to bridge business requirements with IT execution.
BPMN has become the global standard for process modeling not only because it is widely adopted, but because it solves problems that other notations cannot. Its real strength lies in how it supports organizations as they mature in their process management journey.
Many teams start with flowcharts or swimlane diagrams to document processes in an ad-hoc way. While useful, these lack the rules needed to maintain consistency across regions, systems, or business units. BPMN provides that consistency, which is especially important in enterprises operating internationally.
Unlike UML or value stream mapping, BPMN is designed to be readable by business stakeholders while still detailed enough for developers to use as input for automation. This dual purpose has made it the bridge between strategy and execution.
Because BPMN models capture handoffs, exceptions, and decision logic, they make inefficiencies visible in ways simpler diagrams cannot. This makes it easier to identify where to streamline work, enforce standards, or introduce automation.
BPMN’s standardized semantics mean that models created today can be maintained and evolved as systems change. This long-term usability makes it safer to invest in BPMN compared to proprietary or informal notations.
The notation also supports downstream integration with process mining insights—turning discovered “as-is” workflows into optimized “to-be” models
BPMN uses a small set of symbols to represent the different parts of a business process. These shapes may look technical at first, but they are designed to be simple enough for business users to understand while detailed enough for IT to implement.
Below, we break down the main categories of BPMN elements, what they mean in practice, and how they are applied.
Events are circles that mark things happening in a process. They show where a process begins, what interruptions or triggers occur along the way, and how it ends. Without them, a diagram would just be a string of tasks without context. Events help model time-based waits, system messages, or the moment a customer action kicks off the workflow.
Start events show where a process begins. They indicate what kicks off the workflow—whether that’s a customer action, a system signal, or a timer. It initiates a process and triggers the first activity or gateway via a sequence flow connection. Strictly speaking, a process without a start event is never executed.
End events mark where a process finishes and its outcome is delivered. They help clarify the purpose of the process. It occurs after the participants have completed one of the possible activity sequences.
End events can also mark a possible failure to reach the business goal. In our example we fail to achieve the business goal if the products ordered are not available.
In a complete process, the start event is connected to the first task, setting everything else in motion, while the end event connects directly after the final task to clarify the process goal.
Intermediate events capture things that happen between the start and end of a process. They show delays, messages, or waiting points that affect execution.
When combined, start, intermediate, and end events create a complete picture: how a process begins, interacts, and concludes.
Let’s take a look at a job application process: The job applicant writes the application, then sends it via email. In BPMN, this is depicted by a throwing intermediate message event, which indicates that a message is sent.
Now, the company has to wait for the application: The arrival is depicted by a catching intermediate message event, which implies that a message is received. Once this event has been triggered, process execution can proceed.
These are vital when modeling end-to-end journeys discovered through process mining or manual process discovery sessions.
Activities are rounded rectangles that represent the actual work being done. They capture what employees, systems, or bots are responsible for. A task is a single unit of work, while a sub-process bundles multiple related tasks together. Activities are the backbone of BPMN because they make visible where effort, time, and cost are spent.
Tasks represent individual actions, such as “approve invoice” or “send confirmation.”
Tasks are actions which a process participant completes step by step to reach the process’ business goal. Therefore, a task is always assigned to one lane. If multiple persons or roles share a task, you can use the BPMN extension “additional participant”.
If you compare the semantics of a task with natural language, the process participant will be the subject of the process - someone who is doing something. The activity will be the verb, and commonly there is an object in the activity’s labeling: when the process participant performs his action on something, for example a document.
When labeling tasks, you should follow this predefined structure, most typically a verb + object syntax as in “build rocket”.
For sequential execution, tasks are connected by an arrow or the sequence flows. In the example above, the Spacecraft Engineer first thinks and then builds (the) rocket.
Sub-processes group several tasks together under one label. They keep diagrams readable by hiding detail that can be expanded later.
When documenting a process, you often lose track after adding more and more details. The business process may seem too complex to capture in one BPMN diagram.
In this case, sub-processes will help you: They move the details of complex tasks to separate sub-processes.
Here, the details of the write speech tasks are not relevant for the event managers who coordinate the process. That’s why we moved these details into its own process — on a lower level of abstraction:
Activities are connected by Gateways, which determine how flows branch or merge.
→ Related: BPMN Modeling Conventions
Gateways, shown as diamonds, represent decision points or parallel paths in a process. They make business rules explicit so everyone understands how cases move forward. By using gateways, you can show where processes split, merge, or branch depending on conditions.
The most common type of decision is choosing either/or. Exclusive Gateways limit the possible outcome of a decision to a single path, and circumstances choose which one to follow.
In a diagram, the gateway splits the flow—yes or no.
You can also use exclusive gateways to model decisions with more than just two possible outcomes:
In many cases, you want to split up the flow within your business process. For example the Finance and HR departments may examine a new employment contract at the same time. This reduces the total cycle time for a case. To express parallel flow in BPMN, you use a parallel gateway.
A splitting parallel gateway multiplies the incoming sequence flow into several outgoing sequence flows that run simultaneously. A joining parallel gateway waits for all incoming sequences to terminate before combining them all in one outgoing flow.
To allow parallel execution and decision-based exclusion of following sequence flows, you can use the inclusive gateway.
For example: To evaluate a job application, a recruiter might check the applicant’s CV, their cover letter, references and LinkedIn profile. However, depending on what other information the recruiter has, checking all documents is not necessary to make a decision:
Event-based gateways and exclusive gateways are functionally similar. You follow only one path out of the (many) options you have.
But there are two important differences. Event-based gateway are triggered exclusively on intermediate events, and they wait for them to occur, before they trigger a decision — without the process participants’ direct influence. Event-based gateways only consider the first event that occurs.
Gateways supports BPM teams' governance standards and connect with Flows and Connectors, which define sequence and communication.
Flows are arrows that connect elements together and show the order of activities. They turn a set of shapes into a meaningful storyline of how work moves through people and systems. Flows can represent sequential steps, communication between participants, or links to supporting information.
Sequence flows connect activities with each other, as well as with events and gateways to precisely express the order of execution.
Note that sequence flows can only connect elements that are within the same pool: For communication that crosses pool boundaries, use message flows instead.
For communication that crosses the boundaries of your process’ pool, you need to use message flows. To account for additional complexity, communication with message flows needs to be defined more explicitly than intra-pool sequence flow communication. Therefore, BPMN uses events.
Each incoming message is received by a catching event — the organization waits for the corresponding incoming message. Here’s an example:
The delivery address for the package is provided from the order website. Later, you confirm the arrival of the package by sending a message back to the website. Interaction is not limited to activities, but also occurs between pools!
The message flows have these little circles on their tail — that’s where you plug them on the activities (or events) to signalize an outgoing message. Because the different lanes are part of your organizational context, you don’t have any kind of message flows occurring within them — use sequence flows instead.
Associations are dotted connectors that link supporting context—like documents, data objects, notes, or groups—to tasks or events. They do not change the process flow (unlike sequence or message flows); they simply make the model clearer for training, audit, and handovers.
Associations can be directional—have an arrowhead, to indicate read or write access.
When associations don’t express read/write access, we use non-directional associations—without the arrowheads. For a practical example see external participants.
Flows define how tasks connect to Roles and Responsibilities, represented with Swimlanes and Pools.
Swimlanes structure a diagram by clarifying responsibility. Pools represent an entire participant, such as a company or system, while lanes divide a pool into roles or departments. This makes it clear who owns each step and where handoffs occur, which is often where processes break down in real life.
For example, a company (pool) may have three departments (lanes) that collaborate on a business process. Within a department, a set of tasks might always be executed by exactly the same person, which is represented by its own lane.
However, it is more likely that tasks can be carried by all persons who have a specific role. Below, you see a pool that has an organization (research department), role (spacecraft engineer) and a specific person (Mr. Doe) as lanes.
→ Related: Understanding Pools and Lanes
Artifacts add context without changing the flow of the process. They provide supporting information—like documents, notes, or groupings—that makes the diagram more useful for training, audits, or compliance.
A business process usually requires and produces data. Whenever a manager creates a business plan, for example, this document is available for other process participants to read or improve. Data objects make data in your business process explicit.
They don’t provide a complete overview of the data that’s accessed and created, but rather inform the reader about the documents and data stores that are most relevant. As a general rule, you should use data objects to highlight documents (or other data objects) that process participants rely on to resolve a task.
BPMN doesn’t only represent human work—it also shows where systems perform activities. Service tasks and system pools are used to highlight steps executed automatically by IT systems, APIs, or bots.
The IT Systems element is a SAP Signavio-specific extension of BPMN. Many customers use them to explicitly define IT systems that support manual work.
And as you can see in this example model, IT Systems also make an exception. You use non-directional associations to connect them with activities instead of the directional associations you use for other artifacts.
So far there was always one process participant executing one activity — but what happens if there is not exclusively one actor involved? To model reality more concisely the SAP Signavio Process Manager supports the additional participant BPMN extension.
Connect an additional participant via an association to an activity. This expresses that the activity requires this actor’s participation for successful execution.
All these elements make BPMN especially powerful for cross-organizational processes where responsibilities must be crystal clear. Business process teams maintain these relationships through ownership and governance.
While BPMN is the most widely adopted standard for process modeling, it’s not the only option. Different methods suit different needs, from simple flowcharts to complex system diagrams.
Understanding how BPMN compares to other notations helps organizations choose the right tool for the job—or combine them when appropriate.
Flowcharts are one of the simplest ways to visualize processes, using boxes and arrows to show step-by-step actions. They are quick to create and easy to understand but lack the structure and rules of BPMN. BPMN expands on flowcharts by standardizing events, gateways, and responsibilities, making it more suitable for large organizations and automation projects.
UML is designed primarily for modeling software systems rather than business workflows. UML activity diagrams can resemble BPMN but focus on system logic and technical interactions. BPMN, by contrast, centers on business activities and handoffs. In practice, UML is best for software architects, while BPMN is better for business analysts and process teams.
Swimlane diagrams separate tasks by actor or department, helping clarify roles and responsibilities. BPMN incorporates this concept through pools and lanes, but adds more detail about events, flows, and decision logic. Swimlanes alone are useful for basic responsibility mapping, but BPMN provides a fuller picture for governance and compliance.
Gantt charts are project management tools that show tasks over time, dependencies, and deadlines. They are excellent for tracking projects but not designed to model repeatable processes. BPMN, on the other hand, describes workflows independent of time, though the two can be used together—for example, BPMN to model the process, Gantt to schedule its execution in a project.
Value stream mapping comes from Lean methodology and focuses on identifying waste, cycle times, and value-added steps in a process. It gives a high-level view of efficiency but lacks detailed notation for execution. BPMN provides that detail, making it complementary: VSM highlights inefficiencies, while BPMN documents the process to fix them.
SIPOC (Suppliers, Inputs, Process, Outputs, Customers) is a high-level diagram that summarizes process context. It’s particularly useful in Six Sigma projects to define scope. However, SIPOC does not map process steps or decision logic. BPMN provides the detailed flow once the scope is defined.
BPMN is not intended to replace process discovery techniques like workshops, mapping, or mining. Instead, it comes into play once organizations need to design and model processes in a standardized way.
This makes BPMN a cornerstone of process design and optimization, providing the structure required for governance, automation, and compliance.
BPMN is widely used as a modeling technique to document processes in a format that avoids ambiguity. Unlike informal maps, which may reflect how teams think work happens, BPMN diagrams capture start and end points, decision logic, and responsibilities in a consistent, rule-based way. This makes them a reliable reference point for training, audits, or cross-department collaboration.
BPMN serves as a modeling method for defining the “to-be” process in detail. By including rules, exceptions, and system interactions, BPMN ensures redesigned processes are not just aspirational but executable. This makes it easier to evaluate improvement options, identify inefficiencies, and communicate future-state designs to both business and IT.
Because BPMN forces clarity around decision points, approvals, and roles, it produces models that can be used as evidence for compliance. Regulators and auditors can see exactly how a process is intended to run, reducing ambiguity and strengthening governance.
BPMN is particularly valuable in large IT transformations, such as ERP rollouts. As a notation, it helps align business requirements with technical design, preventing inefficiencies from being carried into new systems. BPMN models act as a bridge between business stakeholders and IT configuration teams.
While BPMN is the global standard for process modeling, it’s not without limitations. As with any method, success depends on how it’s applied and by whom. Organizations adopting BPMN often encounter a few recurring challenges:
BPMN can represent very detailed workflows, but this level of detail sometimes creates overly complex “spaghetti diagrams.” If every exception and rule is modeled, diagrams become hard to read for business users. The key is to apply BPMN at the right level of abstraction—using sub-processes and layers to keep models usable.
Compared to simple flowcharts or swimlane diagrams, BPMN requires training to understand its symbols and rules. Business stakeholders may find the notation intimidating at first. Adoption improves when BPMN is introduced gradually, supported by workshops, templates, and clear modeling conventions.
Teams sometimes confuse process mapping with process modeling. Mapping focuses on a human-readable description of workflows, while BPMN provides a standardized model suitable for governance and automation. Using BPMN too early in discovery can slow engagement, but not using it at all risks missing precision.
Although BPMN is a standard, different modeling platforms may implement it with slight variations or additional features. Without clear governance, organizations risk inconsistencies across teams or regions. A shared modeling convention helps ensure BPMN diagrams are comparable and reusable.
BPMN has been the global standard for business process modeling for nearly two decades, and its role is evolving as organizations move deeper into digital transformation.
While the core notation has remained stable, the way it is used is changing.
As organizations continue to modernize, BPMN’s future lies in being the shared language of process design—bridging business needs with technical execution in a way that scales.
Get a BPMN 2.0 overview poster with the various graphical elements, examples of applications, and their meaning.
