BPMN 2.0: The 2026 Reference for European Enterprises
BPMN 2.0: The 2026 Reference for European Enterprises
A working BPMN 2.0 reference for enterprise architects and BPM practitioners — what the standard models well, what it doesn’t, and where it sits in 2026.
BPMN 2.0 has 41 distinct symbol types. Most enterprise process diagrams use 12 of them. The gap between the two numbers is where notation choices either help or hurt a BPM program, and it’s where practitioner-level BPMN knowledge stops being a 101 topic and starts mattering operationally.
For BPM practitioners and enterprise architects building, reviewing, or briefing teams on BPMN 2.0 models in 2026 European enterprises, this reference covers what the standard models well, what it doesn’t, and where it sits in the current platform landscape. The audience is the person who already knows what a BPMN diagram is, and now needs to decide which symbols to use, which to skip, and where BPMN 2.0 hands off to other notations.
What BPMN 2.0 is, and what version we are actually on
Business Process Model and Notation (BPMN) is the OMG-standardised graphical notation for executable process models. The 2.0 specification was first published by the Object Management Group in 2011 and corresponds to the international standard ISO/IEC 19510. The current published version of the BPMN 2.0 specification is 2.0.2; the “2.0” label persists as the canonical reference because no breaking 3.0 release has been made.
BPMN 2.0 defines two things in the same specification. The first is a graphical notation — the symbols, the connection rules, the diagram conventions. The second is a serialisation format (XML) that allows BPMN models to be exchanged between modeling tools and executed by BPMN engines. Both halves matter. A diagram drawn in Visio that “looks like” BPMN but doesn’t conform to the spec cannot be executed by an engine. A model that conforms to the XML schema but uses non-standard symbols can be executed but won’t be readable by another team.
The spec is available at omg.org/spec/BPMN. The 2026 working reality is that BPMN 2.0 is the de-facto standard for executable process modeling in European enterprises and has been for over a decade. The active question is not whether to use BPMN, but which subset of the notation to use and where to stop.
The four element categories
BPMN 2.0 organises its 41 symbol types into four categories. Understanding the categories matters because most real-world BPMN notation mistakes are category mistakes: using a flow object where an artifact belongs, using a swimlane where a flow object belongs, or treating a connecting object as decorative when it carries execution semantics.
Flow Objects are the actual behaviour of the process — events (something happens), activities (work gets done), and gateways (decisions are made). These are the elements the engine executes.
Connecting Objects wire the flow objects together. Sequence flow controls execution order within a process. Message flow shows communication between processes (across pool boundaries). Association connects artifacts to flow objects without affecting execution.
Swimlanes organise the flow objects by participant. A pool represents a process participant — typically a separate organisation, system, or BPMN engine instance. A lane represents a role within a pool, used to allocate work to teams or systems inside a single process.
Artifacts annotate the diagram without affecting execution. Data objects show what information flows through the process. Groups visually cluster related elements. Annotations attach human-readable notes. None of these are executed; they exist for the reader.
The execution implication: if the model needs to drive an engine, only flow objects, connecting objects, and swimlanes carry semantic weight. Artifacts are documentation. A clean BPMN 2.0 model uses artifacts sparingly and resists the temptation to encode logic in annotations that the engine will not execute.
Events: catch versus throw, message versus timer versus signal
Events are the most over-symboled category in BPMN 2.0 and the source of most diagram complexity. The structure is three-by-thirteen: three positions (start, intermediate, end) by thirteen event types (none, message, timer, error, escalation, cancel, compensation, conditional, link, signal, multiple, parallel multiple, terminate), with each combination drawn as a circle with a specific icon and border style. Not every combination is legal, but enough are that the symbol count balloons.
Three distinctions decide most event modeling choices. The first is start, intermediate, or end. Start events trigger a new process instance. End events conclude a process path. Intermediate events sit between activities and either catch (wait for) or throw (signal) something.
The second is catch versus throw, applied to intermediate events. A catch event waits for something to happen — a message arriving, a timer firing, a signal broadcasting. A throw event makes something happen — sending a message, broadcasting a signal. The visual cue is the icon’s fill: a catch event icon is unfilled, a throw event icon is filled.
The third is the event type itself. Message events fire on directed communication between participants. Timer events fire on schedule or duration. Error events propagate exceptions within a process. Signal events broadcast across process boundaries. Conditional events fire when a boolean expression becomes true. Escalation, compensation, link, and the rest cover narrower cases that most enterprise models can ignore.
The practitioner-level guidance: use start, end, message, timer, and error events freely. Use signal events when you genuinely need broadcast semantics across multiple processes. Treat the rest as exceptions that need a justification before they enter a production model.
Activities and gateways: where execution semantics live
Activities are the work units of a BPMN 2.0 process. The base activity is a task — a single unit of work executed once and completed. Tasks have seven defined types: user task (human work in a UI), service task (automated call to an integration), send task (outgoing message), receive task (incoming message), script task (inline script execution), manual task (work tracked but not executed by the engine), and business rule task (decision evaluation, typically delegated to DMN).
Beyond tasks, the spec defines subprocess (a nested process inside the parent), call activity (a reference to a process defined elsewhere), and transaction (a subprocess with ACID semantics). Subprocesses and call activities are how large enterprise BPMN models stay readable. Inlining everything into a single diagram produces a wall of activities that nobody maintains.
Gateways model decision points and parallel paths. Five gateway types cover the cases that matter. The exclusive gateway (XOR) routes the process down exactly one of several outgoing paths based on a condition. The inclusive gateway (OR) can route down multiple paths simultaneously when more than one condition holds. The parallel gateway (AND) always activates all outgoing paths and synchronises them on the converging side. The event-based gateway routes based on which of several events arrives first. The complex gateway covers edge cases not handled by the others; it appears rarely in production models.
The execution implication: gateways drive engine behaviour. An XOR gateway routes one token down one path. An AND gateway forks the token and rejoins it. Misusing gateway types — putting an OR where an XOR belongs, or omitting a converging gateway — produces engine behaviour that does not match the diagram’s apparent intent. This is the second-largest source of BPMN model defects after event mis-typing.
Pools and lanes: modeling responsibility correctly
The pool-versus-lane distinction is the most common modeling confusion in enterprise BPMN 2.0 diagrams. A pool represents a separate process participant. Two pools in a diagram mean two separate processes, communicating through message flow, executable on separate engines or by separate organisations. A lane represents a role inside a single pool, used to allocate work within one process to one team or system.
The practical test: if the work in two swimlanes is executed by the same engine and shares the same process state, they are lanes within one pool. If the work is executed by separate engines, separate systems, or organisations that communicate only by messaging, they are separate pools.
Most enterprise models use too many lanes and too few pools. A BPMN diagram with fifteen lanes covering the whole organisation often hides what is actually a multi-process architecture inside a single pool, with the resulting model being unmaintainable. Splitting into pools at the natural participant boundaries produces models that each fit on a screen, communicate through explicit message flow, and execute on separate engines if needed.
What BPMN 2.0 does not model well
The notation is purpose-built for executable processes with a knowable flow. Four classes of work are systematically poorly served by BPMN 2.0 alone.
Complex decisions. A diamond gateway with a textual condition is fine for simple branching. For decisions with many input variables, many rules, or rule changes that need to be governed independently of the process flow, BPMN 2.0 forces the logic into either a script task (opaque to non-developers) or a fan of gateways (unreadable). The right answer is Decision Model and Notation (DMN), the OMG standard for decision modeling that pairs with BPMN. A BPMN business rule task delegates evaluation to a DMN decision table or decision requirements diagram. The current version is DMN 1.5.
Emergent work and case management. When the flow through the work cannot be drawn in advance — complex claims, regulatory investigations, escalated disputes — BPMN 2.0’s fixed-flow assumption is wrong. The Case Management Model and Notation (CMMN) was developed for this. CMMN’s adoption was narrower than BPMN’s and its standing as a standalone standard has weakened, but the underlying pattern remains: cases are modeled differently to processes. Most modern implementations layer case-management constructs on top of a BPMN engine rather than using CMMN as a standalone notation.
User journeys and customer experience flows. BPMN 2.0 models internal process behaviour. It does not model the customer’s perspective, the cross-channel journey, or the touchpoint-level experience. Customer journey maps and service blueprints sit at a different abstraction layer and don’t compete with BPMN — they precede it.
Data lineage at the field level. BPMN data objects show what data flows through the process. They do not model field-level data transformations, master data dependencies, or data quality rules. For those, enterprise data modeling notations and dedicated data lineage tooling do the job better.
Where BPMN 2.0 sits in 2026 enterprise stacks
The European enterprise BPMN landscape splits into modeling tools and execution engines, with overlap at the platform level but the two concerns often handled by different products.
Modeling tools include Camunda Modeler (free, BPMN-focused, integrates with Camunda engines), ARIS (the dominant DACH process-modeling platform, formerly Software AG), SAP Signavio (acquired by SAP in 2021, strong on collaborative modeling and SAP-stack integration), and BIC Platform from GBTEC (mid-market focus, strong DACH presence). Each tool reads and writes BPMN 2.0 XML, so models can be exchanged between them — within the limits of vendor-specific extensions, which most platforms add.
Execution engines include Camunda 7 (Enterprise supported through April 2030 with paid extended support to April 2032; Community reached End of Life in October 2025), Camunda 8 (the Zeebe-based successor with a different architecture and migration path), Flowable, Activiti, ARIS Process Governance (the execution complement to ARIS modeling), and SAP Signavio Workflow.
Concordia BPM is DNA Automation Consulting’s open AI-powered BPM platform, built on a maintained fork of the Camunda v7 engine with process design, automation, monitoring, and AI Assistant modules layered on top. The same BPMN 2.0 process models that run on Camunda 7 run on Concordia BPM. It sits in the execution layer alongside the other engines listed above and is positioned for enterprises running Camunda 7 in production who want to preserve their v7 process model investment beyond Camunda’s published support window — with an AI-powered platform layer built around the engine rather than a separate fork to maintain.
The 2026 working reality: a typical European enterprise BPMN stack pairs a modeling tool (often ARIS or Signavio for the modeling layer, sometimes Camunda Modeler for engineering-led teams) with an execution engine. The handoff between modeling and execution is where most stack architecture decisions actually live.
Practical guidance for European enterprise architects in 2026
Three working rules cover most BPMN 2.0 modeling decisions in enterprise practice.
Use BPMN 2.0 for the executable process model. Use DMN 1.5 for the decisions inside it. Use a case-management pattern (whether implemented through BPMN extensions, a dedicated case engine, or a platform-native case model) for the emergent work that doesn’t fit a fixed flow. Don’t try to model everything in BPMN; the spec is good at what it does and weak at what it doesn’t.
Keep the symbol vocabulary deliberately narrow. Start, end, message, and timer events; user, service, and business rule tasks; exclusive, parallel, and event-based gateways; subprocesses and call activities for nested structure; pools for participants and lanes for roles. That set covers more than 90% of production enterprise BPMN models. Add other symbols only when the case justifies it.
Treat the modeling tool and the execution engine as separate architectural decisions. The modeling tool is for the people who design and govern the processes. The execution engine is for the people who run them. The two often have different evaluation criteria, different procurement cycles, and different vendor relationships. DNA’s discovery-first methodology treats them separately for a reason: forcing them into a single platform decision tends to compromise one or the other.
A working reference, not the whole standard
BPMN 2.0 is a mature notation, an executable standard, and the operative language for enterprise process modeling in 2026 European industries. The depth of the spec is real, but the working subset that drives most production models is narrow. The harder questions sit at the edges: where BPMN hands off to DMN for decisions, where it hands off to case-management patterns for emergent work, and where the modeling and execution stacks meet at the implementation layer. Those are the questions worth bringing to the IT Director conversation.
Book a meeting
About DNA Automation Consulting
DNA Automation Consulting is an EU-nearshored BPM consultancy based in Split, Croatia. The firm delivers process discovery, BPMN modelling, and automation implementation across ARIS, Camunda, ServiceNOW, SAP Signavio, and Microsoft Power Platform. DNA is also the developer of Concordia BPM, an open AI-powered BPM platform built on a maintained fork of the Camunda v7 engine.
Founded by Ante Gudelj and Nikola Dlaka, both formerly of Software AG (ARIS). Over 75% of DNA’s enterprise engagements last 5 or more years (DNA Automation Consulting, 2026).
Trusted by Proximus, Equinor, Merck, and NEXI.
Frequently asked questions
A working BPMN 2.0 reference for enterprise architects and BPM practitioners — what the standard models well, what it doesn’t, and where it sits in 2026.
BPMN 2.0 has 41 distinct symbol types. Most enterprise process diagrams use 12 of them. The gap between the two numbers is where notation choices either help or hurt a BPM program, and it’s where practitioner-level BPMN knowledge stops being a 101 topic and starts mattering operationally.
For BPM practitioners and enterprise architects building, reviewing, or briefing teams on BPMN 2.0 models in 2026 European enterprises, this reference covers what the standard models well, what it doesn’t, and where it sits in the current platform landscape. The audience is the person who already knows what a BPMN diagram is, and now needs to decide which symbols to use, which to skip, and where BPMN 2.0 hands off to other notations.
What BPMN 2.0 is, and what version we are actually on
Business Process Model and Notation (BPMN) is the OMG-standardised graphical notation for executable process models. The 2.0 specification was first published by the Object Management Group in 2011 and corresponds to the international standard ISO/IEC 19510. The current published version of the BPMN 2.0 specification is 2.0.2; the “2.0” label persists as the canonical reference because no breaking 3.0 release has been made.
BPMN 2.0 defines two things in the same specification. The first is a graphical notation — the symbols, the connection rules, the diagram conventions. The second is a serialisation format (XML) that allows BPMN models to be exchanged between modeling tools and executed by BPMN engines. Both halves matter. A diagram drawn in Visio that “looks like” BPMN but doesn’t conform to the spec cannot be executed by an engine. A model that conforms to the XML schema but uses non-standard symbols can be executed but won’t be readable by another team.
The spec is available at omg.org/spec/BPMN. The 2026 working reality is that BPMN 2.0 is the de-facto standard for executable process modeling in European enterprises and has been for over a decade. The active question is not whether to use BPMN, but which subset of the notation to use and where to stop.
The four element categories
BPMN 2.0 organises its 41 symbol types into four categories. Understanding the categories matters because most real-world BPMN notation mistakes are category mistakes: using a flow object where an artifact belongs, using a swimlane where a flow object belongs, or treating a connecting object as decorative when it carries execution semantics.
Flow Objects are the actual behaviour of the process — events (something happens), activities (work gets done), and gateways (decisions are made). These are the elements the engine executes.
Connecting Objects wire the flow objects together. Sequence flow controls execution order within a process. Message flow shows communication between processes (across pool boundaries). Association connects artifacts to flow objects without affecting execution.
Swimlanes organise the flow objects by participant. A pool represents a process participant — typically a separate organisation, system, or BPMN engine instance. A lane represents a role within a pool, used to allocate work to teams or systems inside a single process.
Artifacts annotate the diagram without affecting execution. Data objects show what information flows through the process. Groups visually cluster related elements. Annotations attach human-readable notes. None of these are executed; they exist for the reader.
The execution implication: if the model needs to drive an engine, only flow objects, connecting objects, and swimlanes carry semantic weight. Artifacts are documentation. A clean BPMN 2.0 model uses artifacts sparingly and resists the temptation to encode logic in annotations that the engine will not execute.
Events: catch versus throw, message versus timer versus signal
Events are the most over-symboled category in BPMN 2.0 and the source of most diagram complexity. The structure is three-by-thirteen: three positions (start, intermediate, end) by thirteen event types (none, message, timer, error, escalation, cancel, compensation, conditional, link, signal, multiple, parallel multiple, terminate), with each combination drawn as a circle with a specific icon and border style. Not every combination is legal, but enough are that the symbol count balloons.
Three distinctions decide most event modeling choices. The first is start, intermediate, or end. Start events trigger a new process instance. End events conclude a process path. Intermediate events sit between activities and either catch (wait for) or throw (signal) something.
The second is catch versus throw, applied to intermediate events. A catch event waits for something to happen — a message arriving, a timer firing, a signal broadcasting. A throw event makes something happen — sending a message, broadcasting a signal. The visual cue is the icon’s fill: a catch event icon is unfilled, a throw event icon is filled.
The third is the event type itself. Message events fire on directed communication between participants. Timer events fire on schedule or duration. Error events propagate exceptions within a process. Signal events broadcast across process boundaries. Conditional events fire when a boolean expression becomes true. Escalation, compensation, link, and the rest cover narrower cases that most enterprise models can ignore.
The practitioner-level guidance: use start, end, message, timer, and error events freely. Use signal events when you genuinely need broadcast semantics across multiple processes. Treat the rest as exceptions that need a justification before they enter a production model.
Activities and gateways: where execution semantics live
Activities are the work units of a BPMN 2.0 process. The base activity is a task — a single unit of work executed once and completed. Tasks have seven defined types: user task (human work in a UI), service task (automated call to an integration), send task (outgoing message), receive task (incoming message), script task (inline script execution), manual task (work tracked but not executed by the engine), and business rule task (decision evaluation, typically delegated to DMN).
Beyond tasks, the spec defines subprocess (a nested process inside the parent), call activity (a reference to a process defined elsewhere), and transaction (a subprocess with ACID semantics). Subprocesses and call activities are how large enterprise BPMN models stay readable. Inlining everything into a single diagram produces a wall of activities that nobody maintains.
Gateways model decision points and parallel paths. Five gateway types cover the cases that matter. The exclusive gateway (XOR) routes the process down exactly one of several outgoing paths based on a condition. The inclusive gateway (OR) can route down multiple paths simultaneously when more than one condition holds. The parallel gateway (AND) always activates all outgoing paths and synchronises them on the converging side. The event-based gateway routes based on which of several events arrives first. The complex gateway covers edge cases not handled by the others; it appears rarely in production models.
The execution implication: gateways drive engine behaviour. An XOR gateway routes one token down one path. An AND gateway forks the token and rejoins it. Misusing gateway types — putting an OR where an XOR belongs, or omitting a converging gateway — produces engine behaviour that does not match the diagram’s apparent intent. This is the second-largest source of BPMN model defects after event mis-typing.
Pools and lanes: modeling responsibility correctly
The pool-versus-lane distinction is the most common modeling confusion in enterprise BPMN 2.0 diagrams. A pool represents a separate process participant. Two pools in a diagram mean two separate processes, communicating through message flow, executable on separate engines or by separate organisations. A lane represents a role inside a single pool, used to allocate work within one process to one team or system.
The practical test: if the work in two swimlanes is executed by the same engine and shares the same process state, they are lanes within one pool. If the work is executed by separate engines, separate systems, or organisations that communicate only by messaging, they are separate pools.
Most enterprise models use too many lanes and too few pools. A BPMN diagram with fifteen lanes covering the whole organisation often hides what is actually a multi-process architecture inside a single pool, with the resulting model being unmaintainable. Splitting into pools at the natural participant boundaries produces models that each fit on a screen, communicate through explicit message flow, and execute on separate engines if needed.
What BPMN 2.0 does not model well
The notation is purpose-built for executable processes with a knowable flow. Four classes of work are systematically poorly served by BPMN 2.0 alone.
Complex decisions. A diamond gateway with a textual condition is fine for simple branching. For decisions with many input variables, many rules, or rule changes that need to be governed independently of the process flow, BPMN 2.0 forces the logic into either a script task (opaque to non-developers) or a fan of gateways (unreadable). The right answer is Decision Model and Notation (DMN), the OMG standard for decision modeling that pairs with BPMN. A BPMN business rule task delegates evaluation to a DMN decision table or decision requirements diagram. The current version is DMN 1.5.
Emergent work and case management. When the flow through the work cannot be drawn in advance — complex claims, regulatory investigations, escalated disputes — BPMN 2.0’s fixed-flow assumption is wrong. The Case Management Model and Notation (CMMN) was developed for this. CMMN’s adoption was narrower than BPMN’s and its standing as a standalone standard has weakened, but the underlying pattern remains: cases are modeled differently to processes. Most modern implementations layer case-management constructs on top of a BPMN engine rather than using CMMN as a standalone notation.
User journeys and customer experience flows. BPMN 2.0 models internal process behaviour. It does not model the customer’s perspective, the cross-channel journey, or the touchpoint-level experience. Customer journey maps and service blueprints sit at a different abstraction layer and don’t compete with BPMN — they precede it.
Data lineage at the field level. BPMN data objects show what data flows through the process. They do not model field-level data transformations, master data dependencies, or data quality rules. For those, enterprise data modeling notations and dedicated data lineage tooling do the job better.
Where BPMN 2.0 sits in 2026 enterprise stacks
The European enterprise BPMN landscape splits into modeling tools and execution engines, with overlap at the platform level but the two concerns often handled by different products.
Modeling tools include Camunda Modeler (free, BPMN-focused, integrates with Camunda engines), ARIS (the dominant DACH process-modeling platform, formerly Software AG), SAP Signavio (acquired by SAP in 2021, strong on collaborative modeling and SAP-stack integration), and BIC Platform from GBTEC (mid-market focus, strong DACH presence). Each tool reads and writes BPMN 2.0 XML, so models can be exchanged between them — within the limits of vendor-specific extensions, which most platforms add.
Execution engines include Camunda 7 (Enterprise supported through April 2030 with paid extended support to April 2032; Community reached End of Life in October 2025), Camunda 8 (the Zeebe-based successor with a different architecture and migration path), Flowable, Activiti, ARIS Process Governance (the execution complement to ARIS modeling), and SAP Signavio Workflow.
Concordia BPM is DNA Automation Consulting’s open AI-powered BPM platform, built on a maintained fork of the Camunda v7 engine with process design, automation, monitoring, and AI Assistant modules layered on top. The same BPMN 2.0 process models that run on Camunda 7 run on Concordia BPM. It sits in the execution layer alongside the other engines listed above and is positioned for enterprises running Camunda 7 in production who want to preserve their v7 process model investment beyond Camunda’s published support window — with an AI-powered platform layer built around the engine rather than a separate fork to maintain.
The 2026 working reality: a typical European enterprise BPMN stack pairs a modeling tool (often ARIS or Signavio for the modeling layer, sometimes Camunda Modeler for engineering-led teams) with an execution engine. The handoff between modeling and execution is where most stack architecture decisions actually live.
Practical guidance for European enterprise architects in 2026
Three working rules cover most BPMN 2.0 modeling decisions in enterprise practice.
Use BPMN 2.0 for the executable process model. Use DMN 1.5 for the decisions inside it. Use a case-management pattern (whether implemented through BPMN extensions, a dedicated case engine, or a platform-native case model) for the emergent work that doesn’t fit a fixed flow. Don’t try to model everything in BPMN; the spec is good at what it does and weak at what it doesn’t.
Keep the symbol vocabulary deliberately narrow. Start, end, message, and timer events; user, service, and business rule tasks; exclusive, parallel, and event-based gateways; subprocesses and call activities for nested structure; pools for participants and lanes for roles. That set covers more than 90% of production enterprise BPMN models. Add other symbols only when the case justifies it.
Treat the modeling tool and the execution engine as separate architectural decisions. The modeling tool is for the people who design and govern the processes. The execution engine is for the people who run them. The two often have different evaluation criteria, different procurement cycles, and different vendor relationships. DNA’s discovery-first methodology treats them separately for a reason: forcing them into a single platform decision tends to compromise one or the other.
A working reference, not the whole standard
BPMN 2.0 is a mature notation, an executable standard, and the operative language for enterprise process modeling in 2026 European industries. The depth of the spec is real, but the working subset that drives most production models is narrow. The harder questions sit at the edges: where BPMN hands off to DMN for decisions, where it hands off to case-management patterns for emergent work, and where the modeling and execution stacks meet at the implementation layer. Those are the questions worth bringing to the IT Director conversation.
Book a meeting
About DNA Automation Consulting
DNA Automation Consulting is an EU-nearshored BPM consultancy based in Split, Croatia. The firm delivers process discovery, BPMN modelling, and automation implementation across ARIS, Camunda, ServiceNOW, SAP Signavio, and Microsoft Power Platform. DNA is also the developer of Concordia BPM, an open AI-powered BPM platform built on a maintained fork of the Camunda v7 engine.
Founded by Ante Gudelj and Nikola Dlaka, both formerly of Software AG (ARIS). Over 75% of DNA’s enterprise engagements last 5 or more years (DNA Automation Consulting, 2026).
Trusted by Proximus, Equinor, Merck, and NEXI.
Frequently asked questions
What is BPMN 2.0?
BPMN 2.0 (Business Process Model and Notation, version 2.0) is the OMG-standardised graphical notation for executable process models. It corresponds to ISO/IEC 19510 and is published at omg.org/spec/BPMN. The current published version of the specification is 2.0.2, with no breaking 3.0 release made.
What is the difference between BPMN and BPMN 2.0?
BPMN 1.x was the original 2004 specification, focused primarily on graphical notation for process diagrams. BPMN 2.0, released in 2011, added formal execution semantics and an XML serialisation that allows models to be executed by BPMN engines. In 2026 enterprise practice, “BPMN” without a version number almost always refers to BPMN 2.0.
How many BPMN 2.0 symbols are there?
BPMN 2.0 defines 41 distinct symbol types across four categories: flow objects (events, activities, gateways), connecting objects, swimlanes (pools and lanes), and artifacts. Most production enterprise models use a working subset of approximately 12 symbols.
Is BPMN 2.0 the right notation for decisions?
No. BPMN 2.0 can express simple branching through exclusive gateways, but complex decision logic — many input variables, many rules, rule governance independent of process flow — fits Decision Model and Notation (DMN) better. A BPMN business rule task typically delegates evaluation to a DMN decision table. The current DMN version is 1.5.
What is a BPMN model and how is it different from a BPMN diagram?
A BPMN model is the underlying executable representation, typically serialised as XML conforming to the BPMN 2.0 specification. A BPMN diagram is the visual rendering of that model. The same model can be rendered as different diagrams (different layouts, different levels of detail), and an engine executes the model, not the diagram.
Which BPMN 2.0 engine should a European enterprise choose in 2026?
The choice depends on the existing footprint. Enterprises with significant Camunda 7 deployments have three paths: Camunda 8 migration (architectural rebuild), Camunda 7 Enterprise renewal (supported through April 2030), or a maintained v7-compatible engine such as Concordia BPM (DNA’s AI-powered BPM platform built on a maintained Camunda v7 fork), CIB seven, EximeeBPMS, Operaton, OrqueIO, ASEE Flow, or Fluxnova. Greenfield deployments more often go to Camunda 8 or Flowable. Enterprises on the SAP stack typically pair with SAP Signavio Workflow; enterprises with mature ARIS modeling pair with ARIS Process Governance.
What is BPMN 2.0?
BPMN 2.0 (Business Process Model and Notation, version 2.0) is the OMG-standardised graphical notation for executable process models. It corresponds to ISO/IEC 19510 and is published at omg.org/spec/BPMN. The current published version of the specification is 2.0.2, with no breaking 3.0 release made.
What is the difference between BPMN and BPMN 2.0?
BPMN 1.x was the original 2004 specification, focused primarily on graphical notation for process diagrams. BPMN 2.0, released in 2011, added formal execution semantics and an XML serialisation that allows models to be executed by BPMN engines. In 2026 enterprise practice, “BPMN” without a version number almost always refers to BPMN 2.0.
How many BPMN 2.0 symbols are there?
BPMN 2.0 defines 41 distinct symbol types across four categories: flow objects (events, activities, gateways), connecting objects, swimlanes (pools and lanes), and artifacts. Most production enterprise models use a working subset of approximately 12 symbols.
Is BPMN 2.0 the right notation for decisions?
No. BPMN 2.0 can express simple branching through exclusive gateways, but complex decision logic — many input variables, many rules, rule governance independent of process flow — fits Decision Model and Notation (DMN) better. A BPMN business rule task typically delegates evaluation to a DMN decision table. The current DMN version is 1.5.
What is a BPMN model and how is it different from a BPMN diagram?
A BPMN model is the underlying executable representation, typically serialised as XML conforming to the BPMN 2.0 specification. A BPMN diagram is the visual rendering of that model. The same model can be rendered as different diagrams (different layouts, different levels of detail), and an engine executes the model, not the diagram.
Which BPMN 2.0 engine should a European enterprise choose in 2026?
The choice depends on the existing footprint. Enterprises with significant Camunda 7 deployments have three paths: Camunda 8 migration (architectural rebuild), Camunda 7 Enterprise renewal (supported through April 2030), or a maintained v7-compatible engine such as Concordia BPM (DNA’s AI-powered BPM platform built on a maintained Camunda v7 fork), CIB seven, EximeeBPMS, Operaton, OrqueIO, ASEE Flow, or Fluxnova. Greenfield deployments more often go to Camunda 8 or Flowable. Enterprises on the SAP stack typically pair with SAP Signavio Workflow; enterprises with mature ARIS modeling pair with ARIS Process Governance.
What is BPMN 2.0?
BPMN 2.0 (Business Process Model and Notation, version 2.0) is the OMG-standardised graphical notation for executable process models. It corresponds to ISO/IEC 19510 and is published at omg.org/spec/BPMN. The current published version of the specification is 2.0.2, with no breaking 3.0 release made.
What is the difference between BPMN and BPMN 2.0?
BPMN 1.x was the original 2004 specification, focused primarily on graphical notation for process diagrams. BPMN 2.0, released in 2011, added formal execution semantics and an XML serialisation that allows models to be executed by BPMN engines. In 2026 enterprise practice, “BPMN” without a version number almost always refers to BPMN 2.0.
How many BPMN 2.0 symbols are there?
BPMN 2.0 defines 41 distinct symbol types across four categories: flow objects (events, activities, gateways), connecting objects, swimlanes (pools and lanes), and artifacts. Most production enterprise models use a working subset of approximately 12 symbols.
Is BPMN 2.0 the right notation for decisions?
No. BPMN 2.0 can express simple branching through exclusive gateways, but complex decision logic — many input variables, many rules, rule governance independent of process flow — fits Decision Model and Notation (DMN) better. A BPMN business rule task typically delegates evaluation to a DMN decision table. The current DMN version is 1.5.
What is a BPMN model and how is it different from a BPMN diagram?
A BPMN model is the underlying executable representation, typically serialised as XML conforming to the BPMN 2.0 specification. A BPMN diagram is the visual rendering of that model. The same model can be rendered as different diagrams (different layouts, different levels of detail), and an engine executes the model, not the diagram.
Which BPMN 2.0 engine should a European enterprise choose in 2026?
The choice depends on the existing footprint. Enterprises with significant Camunda 7 deployments have three paths: Camunda 8 migration (architectural rebuild), Camunda 7 Enterprise renewal (supported through April 2030), or a maintained v7-compatible engine such as Concordia BPM (DNA’s AI-powered BPM platform built on a maintained Camunda v7 fork), CIB seven, EximeeBPMS, Operaton, OrqueIO, ASEE Flow, or Fluxnova. Greenfield deployments more often go to Camunda 8 or Flowable. Enterprises on the SAP stack typically pair with SAP Signavio Workflow; enterprises with mature ARIS modeling pair with ARIS Process Governance.
Written by:
DNA Consulting
Content Creator
Share with friends: