BPMN 2.0 is the most comprehensive process modeling standard, with precisely defined notation and an underlying formal meta-model.

However, this precision comes at the cost of a complex and sometimes un-transparent specification, which is more suited to BPMN vendors as to modelers.

Consequently, modelers commonly learn about BPMN from secondary sources (e.g. books, blogs and whitepapers). These BPMN learning materials simplify and speed-up the adoption of BPMN, however commonly at the cost of omitting details. The remainder of this paper will present 10 facts, which are defined in the BPMN 2.0 specification, you probably didn’t know.

1. When a task is executed depends from the task type

You’d think that a task starting to execute immediately after the previous task would have completed? Not necessarily.

It depends on the task type, since the task execution and completion differs between the task types. In general, an activity (i.e. a task and a sub-process) is ready for execution if the required number of tokens is available to activate the activity.

An activity afterwards changes from ready to active, when the required input data is available. In case of automated tasks (e.g. service task, script task and send task), the task is staring to execute upon activation, where in the case of human tasks (i.e. user task and manual task) the task is distributed to the assigned person or group of people (see BPMN 2.0 pages 428-430).

diagram-1

Figure: Task execution and completion differs between the task types.

To summarize, you actually cannot anticipate when a human task will be finished, since it depends on the human performer of the task.

2. Most message flows are mandatory, some are optional

A message flow is used to show the flow of messages between two participants that are prepared to send and receive them. Only a pool/participant, activity, and event elements can connect to message flows.

Free BPMN Downloads!

In some cases, a message flow indicates an optional communication, where in other cases it indicates a mandatory communication. In the case of a user task with an outgoing message flow, the communication is optional (i.e. a user task MAY send a message). On the other hand, a mandatory communication is defined by message events or send and receive tasks.

diagram-2

Figure: Most message flows are mandatory, some are optional

3. Why two mandatory start events will never end a process?

Assume that you want to start a process (i.e. instantiate a process) when two start events occur (see figure below).

http://blog.goodelearning.com/wp-content/uploads/2014/09/diagram-3.jpg

Figure: This process will never finish

Unfortunately, this process will never come to the end, since every occurrence of a start event (event 1 or event 2) would instantiate a new process. Consequently, each process instance will be stuck at the parallel gateway.

The best solution for this problem is to use a parallel event-based gateway to start a process (see BPMN 2.0, page 299).

4. Start and end events are optional

Do you think that the process below is incomplete, since the start and end events are missing? You are wrong.BPMN Facts

Figure: Regular BPMN 2.0 diagram

According to BPMN 2.0 specification, the use of start and end events is optional:

BPMN 2.0, page 238:

A Start Event is OPTIONAL: a Process level—a top-level Process, a Sub-Process (embedded), or a Global Process (called Process)—MAY (is NOT REQUIRED to) have a Start Event.

BPMN 2.0, page 246:

An End Event is OPTIONAL: a given Process level—a Process or an expanded Sub-Process—MAY (is NOT REQUIRED to) have this shape.

5. When is a sub-process finished?

Usually a sub-process is finished, when it reaches all it’s end-states (see figure below):

BPMN 2.0, page 431:

A Sub-Process instance completes when there are no more tokens in the Sub-Process and none of its Activities is still active.

diagram-5
Figure: A sub-process is finished, when it reaches all its end-states

However, this statement doesn’t apply to an ad-hoc sub-process, which is marked with a “~” symbol placed at the bottom-center of the sub-process shape. An ad-hoc sub-process is a specialized type of a sub-process, composed of a group of activities that have no required sequence relationships (i.e. sequence flows).

In an ad-hoc sub-process, a set of activities can be defined for the process, but the sequence and number of performances for the activities is determined by the performers of the activities. Since each activity of an a-hoc sub-process may be executed zero or many times, an ad-hoc sub-process completes without executing further if the completion condition is set to true (user defined). See BPMN 2.0 on page 431 for more information.

6. Message events and message tasks are equal, almost

In many BPMN sources, message events and send/receive tasks are treated as equal.BPMN Facts

Figure: A sub-process is finished, when it reaches all its end-states

However, there are some differences between them. Firstly, we can attach several different boundary events to send and receive tasks (see left figure below). Furthermore, additional markers can be added to the tasks (e.g. to represent loops and multiple instances).

On the other hand, intermediate catching of message events can be attached to activities in order to represent an exceptional flow (see right figure below).

BPMN Facts Figure: A sub-process is finished, when it reaches all its end-states

7. Free flowing text annotation

You think that the diagram below is invalid since the third comment isn’t connected to any BPMN element? You are wrong.

BPMN 2.0 (page 71) states:

A Text Annotation object CAN be connected to a specific object on the Diagram with an Association, but does not affect the flow of the Process.

The “CAN” in the statement means that the “comment” association is optional.

BPMN Facts
Figure: Free flowing text annotation

8. A regular sub-process may consist of disconnected activities

Did you think that the following diagram is invalid because the activities aren’t connected with sequence flows? You are wrong.BPMN Facts

Figure: An expanded sub-process used as a “parallel box”

Since start and end events are optional, the above diagram equals to the below one.

BPMN 2.0 (page 174) states that expanded sub-processes can be used as a mechanism for showing a group of parallel activities in a less-cluttered, more compact way. Anyway, a more common and unambiguous approach is to use explicit start and end events as presented below:BPMN Facts

Figure: An expanded sub-process used as a “parallel box” with explicit start and end events

9. No use case for a diverging complex gateway?

Each BPMN gateway can be used for modeling different process convergence or divergence behaviors. However, in case of a complex gateway, the diverging behavior is semantically equal to the behavior of an inclusive gateway. BPMN 2.0 (page 295) states that:

The Complex Gateway can be used to model complex synchronization behavior. An Expression activation Condition is used to describe the precise behavior.

For example, this Expression could specify that tokens on three out of five incoming Sequence Flows are needed to activate the Gateway. What tokens are produced by the Gateway is determined by conditions on the outgoing Sequence Flows as in the split behavior of the Inclusive Gateway.BPMN Facts

Figure: Splitting behavior of a complex gateway and inclusive gateway is the same

A minor difference in case of the splitting behavior is that the complex gateway uses a single outgoing assignment within the gateway, rather than a set of separate conditions on the outgoing sequence flows.

10. How many messages may an event send or receive?

It depends from the type of a message event. In case of intermediate message events, BPMN specification states that only one message flow is allowed (BPMN 2.0, page 260):

Message Intermediate Event MAY be the target for a Message Flow; it can have one incoming Message Flow. A Message Intermediate Event MAY be a source for a Message Flow; it can have one outgoing Message Flow.

In case of start and end message events, BPMN specification states that several message flows are allowed:BPMN FactsFigure: Message events and message flows

Conclusion

This article presented some BPMN 2.0 facts which are buried deeply into the specification and therefore invisible to the majority of modelers.

Since some of the stated facts might be defined un-clearly, your feedback is very welcome! So please do post your thought’s and comments below in the comment section.

Free BPMN Resources

SHARE
Previous articleThe Missing Role of the Segment Architect
Next articleIs the TOGAF ADM Too Reactive? Read More and Find Out!
Gregor received his PhD in 2008 in the fields of software engineering and information systems and has nearly a decade of experience in BPMN, starting to investigate and actively use BPMN since its introduction in 2004. In addition, he has participated in the development of one of the first BPMN modeling utilities - a package of plugins for Visio, which were introduced early in 2005 and is the main author of the first BPMN poster (bpmn.itposter.net), which has been translated into several languages and already exceeded 50.000 downloads.