Appendix: BPMN 2.0 Reference

This appendix contains a brief description of all of the BPMN 2.0 elements and their visual representation in BPMN2 Modeler. There is also a detailed discussion of the supported diagram types.



An Association is used to link information and Artifacts with BPMN graphical elements. Text Annotations and other Artifacts can be associated with the graphical elements. An arrowhead on the Association indicates a direction of flow, when appropriate.

Conversation Link

Conversation Links are used to connect Conversations to and from Participants (Pools)

Data Association

Data Associations show a flow of data out of, or in to an Activity. An arrow head is used to indicate the direction of the data flow.

Data Associations are used to move data between Data Objects, Process Variables, and inputs and outputs of Activities, Processes, and Global Tasks. Process execution does not flow along a Data Association, and as a result they have no direct effect on the flow of the Process. The purpose of retrieving data from Data Objects or Process Data Inputs is to fill the Activities inputs and later push the output values from the execution of the Activity back into Data Objects or Process Data Outputs.

Message Flow

A Message Flow is used to show the flow of Messages between two Participants. Pools in a Collaboration Diagram are used to represent the two Participants.

Sequence Flow

A Sequence Flow is used to show the order in which Activities will be performed in a Process or Choreography. A Sequence Flow can optionally define a condition Expression, indicating that control will be passed down the Sequence Flow only if the Expression evaluates to true. This Expression is typically used when the source of the Sequence Flow is a Gateway or an Activity. A Sequence Flow that has an Exclusive, Inclusive, or Complex Gateway or an Activity as its source can also be defined as "default". Such a Sequence Flow will have a marker to show that it is a default flow. The default Sequence Flow is taken only if all the other outgoing Sequence Flows from the Activity or Gateway are not valid (i.e., their condition Expressions are false).


Boundary Event

Boundary Events are attached to the borders of an Activity and are used to handle conditions (Event Definitions) that may have resulted during execution of the Activity.

End Event

As the name implies, the End Event indicates where a Process will end. In terms of Sequence Flows, the End Event ends the flow of the Process, and thus, will not have any outgoing Sequence Flows and no Sequence Flow can connect from an End Event. An End Event may have one or more triggers (Event Definitions), which are passed back to an invoking or containing Process (if any).

Intermediate Catch Event

The Intermediate Catch Event is used to handle some kind of condition (Event Definition) that has occurred within the process or in an external process.

Intermediate Throw Event

The Intermediate Throw Event is used to report some kind of condition (Event Definition) to an invoking or containing Process. The receiving Process should be designed so that it is prepared to handle the event, either with a Start Event, Intermediate Catch Event or a Boundary Event.

Start Event

As the name implies, the Start Event indicates where a particular Process will start. In terms of Sequence Flows, the Start Event starts the flow of the Process, and thus, will not have any incoming Sequence Flows and no Sequence Flow can connect to a Start Event. A Start Event may have one or more event triggers (Event Definitions) which cause the Process to be initiated.

Event Definitions

Event Definitions determine the behavior of Events. An Event may have zero or more Event Definitions.


This type of Event Definition is only allowed when used within a Transaction Sub-Process. It is used to “roll back” the effects of the Transaction.


Compensation is similar to a Cancel Event in that it is used to reverse the effects of one or more Activities. In this case, the Activities may not be contained in a Transaction Sub-Process, so each Activity needs to be compensated separately.


This type of Event is triggered when a condition becomes true. The Event Definition contains the condition Expression.


An Error Event Definition is used to throw or catch an Error. The Error payload is associated with a variable owned by the Event. See Error below, for more details.


An Escalation Event Definition is used to throw or catch an Escalation. The Escalation payload is associated with a variable owned by the Event. See Escalation below, for more details.


A Link is a mechanism for connecting two sections of a Process. Link Events can be used to create looping situations or to avoid long Sequence Flow lines. Link Event uses are limited to a single Process level (i.e., they cannot link a parent Process with a Sub-Process). Paired Intermediate Events can also be used as “Off-Page Connectors” for printing a Process across multiple pages. They can also be used as generic “Go To” objects within the Process level.


A Message Event Definition can be used to either send or receive a Message. The Message payload is associated with a variable owned by the Event. See Message below, for more details.


A Signal Event Definition is used to throw or catch a Signal. See Signal below, for more details.


This type of End Event indicates that all Activities in the Process should be immediately ended. This includes all instances of multi-instances. The Process is ended without compensation or event handling.


The Timer Event Definition acts as a delay mechanism based on a specific time-date or a specific cycle (e.g., every Monday at 9am) can be set that will trigger the Event.


A Gateway must have multiple incoming or multiple outgoing Sequence Flows (i.e., it must either merge or split the process flow). The Gateway Direction property determines its behavior; this property can be one of the following

·         Unspecified – the Gateway may have both multiple incoming and outgoing Sequence Flows

·         Mixed – the Gateway must have both multiple incoming and outgoing Sequence Flows

·         Converging – the Gateway must have multiple incoming Sequence Flows, but may have only one outgoing Sequence Flow

·         Diverging– the Gateway may have only one incoming Sequence Flow, but must have multiple outgoing Sequence Flows

Complex Gateway

The Complex Gateway can be used to model complex synchronization behavior. An Expression is used to describe the precise behavior. For example, this Expression could specify that three out of five incoming Sequence Flows are needed to activate the Gateway. The outgoing paths that are taken by the Gateway, is determined by conditions on the outgoing Sequence Flows as in the split behavior of the Inclusive Gateway.

Exclusive Gateway

A diverging Exclusive Gateway (decision) is used to create alternative paths within a Process flow. This is basically the "diversion point in the road" for a Process. For a given instance of the Process, only one of the paths can be taken. A decision can be thought of as a question that is asked at a particular point in the Process. The question has a defined set of alternative answers. Each answer is associated with a condition Expression that is associated with a Gateway's outgoing Sequence Flows.

A default path can optionally be identified, to be taken in the event that none of the conditional Expressions evaluate to true. If a default path is not specified and the Process is executed such that none of the conditional Expressions evaluates to true, a runtime exception occurs.

A converging Exclusive Gateway is used to merge alternative paths.

Event Based Gateway

The Event-Based Gateway represents a branching point in the Process where the alternative paths that follow the Gateway are based on events that occur, rather than the evaluation of expressions using Process data (as with an Exclusive or Inclusive Gateway). A specific event, usually the receipt of a Message, determines the path that will be taken. Basically, the decision is made by another Participant based on data that is not visible to a Process, thus requiring the use of the Event-Based Gateway.

Inclusive Gateway

A diverging Inclusive Gateway (inclusive decision) can be used to create alternative but also parallel paths within a Process flow. Unlike the Exclusive Gateway, all condition expressions are evaluated. The true evaluation of one condition expression does not exclude the evaluation of other condition expressions. All Sequence Flows with a true evaluation will be traversed. Since each path is considered to be independent, all combinations of the paths may be taken, from zero to all. However, it should be designed so that at least one path is taken.

A default path can optionally be identified, to be taken in the event that none of the conditional Expressions evaluate to true. If a default path is not specified and the Process is executed such that none of the conditional Expressions evaluates to true, a runtime exception occurs.

A converging Inclusive Gateway is used to merge a combination of alternative and parallel paths.

Parallel Gateway

A Parallel Gateway is used to synchronize (combine) parallel flows and to create parallel flows. A Parallel Gateway creates parallel paths without checking any conditions; each outgoing Sequence Flow is passed control upon execution of this Gateway. For incoming flows, the Parallel Gateway will wait for all incoming flows before triggering the flow through its outgoing Sequence Flows.


Business Rule Task

A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide.

Choreography Task

A Choreography Task is an atomic Activity in a Choreography Process. It represents an Interaction, which may be one or two Message exchanges between two Participants.




Manual Task

A Manual Task is a task that is not managed by any business process engine. It can be considered as an unmanaged task, in the sense that the business process engine does not track the start and completion of such a task. An example of this could be a paper based instruction for a telephone technician to install a telephone at a customer location.

Receive Task

A Receive Task is a simple task that is designed to wait for a Message to arrive from an external Participant (relative to the Process). Once the Message has been received, the task is completed.

Script Task

A Script Task is executed by a business process engine The modeler or implementer defines a script in a language that the engine can interpret When the task is ready to start, the engine will execute the script When the script is completed, the task will also be completed.

Send Task

A Send Task is a simple task that is designed to send a Message to an external Participant (relative to the Process). Once the Message has been sent, the task is completed.


Service Task

A Service Task is a task that uses some sort of service, which could be a Web service or an automated application.

A Service Task defines an Implementation which is the underlying technology that will be used to implement the service. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol.


A Task is an atomic Activity that is included within a Process. A Task is used when the work in the Process is not broken down to a finer level of Process detail.


User Task

A User Task is a typical workflow task where a human actor performs the task with the assistance of a software application. The lifecycle of the task is managed by a software component (called the “Task Manager”) and is typically executed in the context of a Process. The User Task can be implemented using different technologies, specified by the Implementation attribute. Besides the Web service technology, any technology can be used. A User Task for instance can be implemented using WSHumanTask by setting Implementation to “”.

Data Elements

This section describes all of the possible data elements that can be manipulated by Activities in a Process, both visual and non-visual.

The BPMN 2.0 spec also provides for a “Data State”, which is a state of the data contained in a data element. The definition of these states, e.g., possible values, and any specific semantics are out of scope of the BPMN 2.0 spec. Therefore, BPMN adopters can use this element and the BPMN extensibility capabilities to define their own states.

 Data Input/Output

Activities and Processes often required data in order to execute. In addition they may produce data during or as a result of execution. Data requirements are captured as Data Inputs and Data Outputs.


Input and Output Sets

An Activity or Process may be designed such that it can execute with differing sets of input data. This allows the process architect greater flexibility in designing the process, since not all data may be available or even required when executing an Activity. For example, some information (e.g. a city name) can be derived or looked up (by, e.g. city postal code) if not provided to the Activity at runtime. This is similar to the concept of method overloading in Java or C++.

BPMN 2.0 introduced the concept of Input Sets and Output Sets to support this concept. Essentially, Data Inputs, when grouped together (the “Input Set”), define a valid set of data inputs for an Activity. Data Outputs grouped together (the “Output Set”) define the set of data items produced when the Activity completes. These Input and Output Sets also allow you to specify which data items are optionally available on input or optionally created on output, and which items are required or mandatory.

Input and Output Sets can also define mutual dependencies; an Input Set can indicate which Output Sets are produced, and an Output Set can indicate the Input Sets needed to produce the output data.

Data Object

Data Objects are the primary construct for modeling data within the Process flow. A Data Object has a well-defined lifecycle and structure. A Data Object can appear multiple times in a Process diagram, each of which references the same Data Object instance. These references are used to simplify diagram connections.

Data Store

A Data Store provides a mechanism for Activities to retrieve or update stored information that will persist beyond the scope of the Process. The same Data Store can be visualized, through a Data Store Reference, in one or more places in the Process.



A Message represents the content of a communication between two Participants.



An Error represents the content of an Error Event or the Fault of a failed Operation.


An Escalation identifies a business situation that a Process might need to react to.


Signals are triggers generated in the Pool they are published. They are typically used for broadcast communication within and across Processes, across Pools, and between Process diagrams.


A Resource is an actor or responsible party that participates in an activity. This could be, for example, a specific individual, a group, an organization role or position, or an organization. Resources are assigned to Activities during Process execution time.

A Resource may need additional information to complete a task. This could be, for example, a customer’s contact information, an order request, invoice, etc. This information is represented as Resource Parameters. In an executable Process, Resource Parameters must be in the form of data items that are accessible within the scope of the Activity that owns the Resource.

Variable (Property)

Properties, like Data Objects, are data containers. But, unlike Data Objects, they are not visually displayed on a diagram. Only Processes, Activities, and Events may contain Properties. Properties are analogous to “Variables” in the context of a programming language, in that they are used to store, transform and convey data as it is moved through the process. Properties have the same properties as Data Objects, in that they have a well-defined structure, kind and cardinality.

BPMN2 Modeler uses the term “Variable” instead of “Property” because it seems more intuitive to the software developer, though they refer to the same BPMN2 model element. Also, because the term “Property” is so ubiquitous it can sometimes cause confusion when discussing the “properties of a Property”.

Data Type (ItemDefinition)

BPMN elements, such as Data Objects and Messages, represent items that are manipulated during process flows. The set of characteristics that describe these items are known in BPMN 2.0 as Item Definitions. However, since BPMN2 Modeler is designed primarily with the software engineer in mind, it uses the more intuitive name “Data Type”.

Item Definitions can be either “Physical”, such as the mechanical part of a vehicle, or “Informational” such as the catalog of the mechanical parts of a vehicle. This is known as the “Item Kind”. If the item is Informational, then its data structure must also be provided in the Item Definition.

It is also possible to define collections of items by setting the “is collection” flag. No assumption is made about the ordering of the items in the collection.


Ad Hoc Sub Process

An Ad-Hoc Sub-Process contains any number of embedded inner Activities and is intended to be executed with a more flexible ordering compared to the typical routing of Processes. The contained Activities are executed sequentially or in parallel, they can be executed multiple times in an order that is only constrained through the specified Sequence Flows, Gateways, and data connections.

Call Activity

A Call Activity identifies a point in the Process where a global Process or a Global Task is used. The Call Activity acts as a wrapper for the invocation of a global Process or Global Task within the execution. The activation of a Call Activity results in the transfer of control to the called global Process or Global Task.

Call Choreography

A Call Choreography identifies a point in the Process where a global Choreography or a Global Choreography Task is used. The Call Choreography acts as a place holder for the inclusion of the Choreography element it is calling.



A Lane is a sub-partition within a Process (often within a Pool) used to organize and categorize Activities within a Pool. Lanes are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), an internal department (e.g., shipping, finance), etc. In addition, Lanes can be nested or defined in a matrix. For example, there could be an outer set of Lanes for company departments and then an inner set of Lanes for roles within each department.


A Pool is the graphical representation of a Participant in a Collaboration or Choreography and can be a specific Partner Entity (e.g., a company) or can be a more general Partner Role (e.g., a buyer, seller, or manufacturer). A Pool may reference a Process, but is not required to, i.e., it can be a “black box”.

Sub Choreography

A Sub-Choreography is a compound Activity in that it has detail that is defined as a flow of other Activities, in this case, a Choreography. Each Sub-Choreography involves two or more Participants. The name of the Sub-Choreography and each of the Participants are all displayed in the different bands that make up the graphical notation. There are two or more Participant Bands and one Sub-Process name band.

Sub Process

A Sub-Process is an Activity whose internal details have been modeled using Activities, Gateways, Events, and Sequence Flows. Sub-Processes define a contextual scope that can be used for attribute visibility, transactional scope, for the handling of exceptions, of events, or for compensation. A Sub-Process can be in a collapsed view that hides its details or in an expanded view that shows its details within the view of the Process in which it is contained.

If a Sub-Process is declared as an event handler (the “Is Triggered by Event” flag is set), it is not part of the normal process flow and must be configured as follows:

·         It may not have any incoming or outgoing Sequence Flows.

·         It must have one and only one Start Event trigger that has one or more of the following Event Definitions:

o    Message

o    Error

o    Escalation

o    Compensation

o    Conditional

o    Signal

There are two possible consequences to the parent Process when an Event Sub-Process is triggered:

1.    the parent Process can be interrupted

2.    the parent Process can continue its work (not interrupted)

This is determined by whether the Start Event that is used has the “Is Interrupting” flag set.


A Transaction is a specialized Sub-Process that is executed atomically, that is, all of its contained activities either execute successfully to completion, or their combined effects (primarily on data) are rolled back.

Transactions must specify a Transaction Protocol and the Method used to commit or cancel the transaction. The Protocol should be set to a technology specific URI, e.g., for WSAtomicTransaction, or for WS-BusinessActivity.



A Conversation is an atomic element for a Conversation (Collaboration) diagram. It represents a set of Message Flows grouped together based on a concept and/or a Correlation Key. A Conversation will involve two or more Participants.


The Group object is an Artifact that provides a visual mechanism to group elements of a diagram informally. A Group is not an Activity or any Flow Object and therefore, cannot connect to Sequence Flows or Message Flows. In addition, Groups are not constrained by restrictions of Pools and Lanes. This means that a Group can stretch across the boundaries of a Pool to surround diagram elements, often to identify Activities that exist within a distributed business-to-business transaction. Groups are often used to highlight certain sections of a diagram and do not affect the flow of the Process.

Text Annotation

Text Annotations provide additional information to the reader about a BPMN diagram.


Diagram Types

As a software developer involved in implementing a BPM system for your organization or for a customer you are probably focused mainly on defining user roles, work activities, process flow logic, exception handling, making sure all of the data structures are properly defined and all of the endpoints are correct, and so on. Sometimes it feels like you're too close to the forest to see the trees.

The smart folks that make up the OMG understand that business processes can be extremely complex and that no one type of diagram can capture all of the details required to fully understand the inner workings of a large enterprise, much less how one organization interacts with others in the business world. That is why the spec defines several types of diagrams, which present different views of a business process. This section discusses these diagram types and how they are intended to be used.

Process Diagrams

This is the "boxes and arrows" flow chart type of diagram that defines the activities ("boxes") their sequencing ("arrows"), decision branches ("diamonds") and so on. This type of diagram typically represents an Organization's private process, i.e. a description of how an Organization works internally. While the diagram may show information (in the form of "messages") coming in from, or leaving the Organization to the outside world, this type of diagram is not intended to show interactions between different Organizations.

It's also possible to describe two or more departments interacting with each other inside the Organization using "swim lanes" (or just “Lanes”). Swim lanes can be nested to reflect the Organization's departmental hierarchy and individual roles within a department. Here's an example showing the product development cycle in a software consulting firm:


Figure 76: Example Process Diagram

Collaboration Diagrams

This type of diagram shows the interactions between two or more processes, typically owned by different parties or Organizations. The processes are represented by "Pools" and, as with Process Diagrams, each Pool may contain one or more Lanes. Collaboration Diagrams are similar to Process Diagrams in that they depict the flow of activities internal to an Organization; the difference is whereas a Process Diagram is used to depict a single process, Collaboration Diagrams show multiple processes as well as the interface points between them.

Here's a Collaboration Diagram illustrating a Pizza order:


Figure 77: Example Collaboration Diagram

Choreography Diagrams

Choreography Diagrams are mainly focused on the participants ("Pools") in a business process and the information exchanged between them, rather than on the orchestration of the work being performed. A Choreography Diagram can be thought of as a business contract between two or more Organizations.

Here's a Choreography Diagram showing the interaction between a buyer and an online retailer. Each exchange is represented by a rounded rectangle, called a Choreography Task; the information exchanged between them is shown as an envelope representing a message sent from the initiating participant.


Figure 78: Example Choreography Diagram

Conversation Diagrams

These are a simplification of a Choreography Diagram and are intended as an overview to illustrate which participants co-operate on which tasks. Conversations, as you would guess, are exchanges of packets of information ("Messages") related to the completion of a task.

In Conversation Diagrams, the participants are represented as Pools, similar to the Collaboration Diagram, and the information exchange (Conversation) as a hexagon connecting them, as shown here:


Figure 79: Example Conversation Diagram

Conversation Diagrams are not yet fully supported by the BPMN2 Modeler, but they are planned as an enhancement for a future release.