Various BPMN™ objects can be characterized in order to add additional information in a model. The available characterizations are listed in the tables below. The characterizations are marked using an icon that appears in the object upon the assignment of a characterization.

The list below is not complete. For a more detailed explanation and application of the BPMN objects, their characterizations, and properties, please refer to the official BPMN specification, or visit the website of the Object Management Group® (OMG).


On this page:


Task types

Task characterizations are used to specify what type of action should be executed. 

Symbol

Type + description

Send task

A simple task for sending a message to an external participant (from the perspective of the process). Upon sending the message, the task is completed.



Receive task

A simple task for waiting on a message from an external participant (from the perspective of the process). Upon receiving the message, the task is completed.



Manual task

A manual task that is executed without the support of an application or machine that executes the business process.



User task

A typical workflow task that is executed by a person supported by a software application.



Service task

A task that uses some sort of service, for example, a web service or an automated application. The task is (usually) executed fully automated.



Business rule task

A mechanism for the process to deliver input for a "business rule engine" (software system) and receiving the output of calculations from a business rule engine.



Script task

A task that is executed out by a "business process engine" (BPE). For this task, a script needs to be defined that can be interpreted by a business process engine.

As soon as the task is ready for execution, the business process engine will execute the script. Upon completion of the script, the task will be completed as well. The task is executed fully automated.



Event types

Besides the event types listed below, events can also be specified as (non-)interrupting, catching, throwing or as a boundary event. Whether or not a characterization is available for an event, depends on the type of event (start, intermediate, boundary, end), and its characterization.

Symbol

Type + description

none

Untyped

Events without a characterization such as a starting point or change of status. It does not have a trigger or result specified.



Message event

Messages are being sent or received.

For a start event, this means that the process is triggered by an external signal: a message.

In case of an intermediate event, the event sends or receives a message as a signal between the process and an external entity.

In case of a boundary event, the event is triggered by a message that can be received.

In case of an end event, the event sends a message to an external participant.



Timer event

In case of a start event, this characterization is used to show that the process is executed based on a predefined time schedule, one time only, or recurring.

For an intermediate event, this characterization can be used to configure a certain delay. This means that a delay of a specific duration is applied, or that the process waits until a specific time or date before it continues to execute.

In case of a boundary timer event, the event behaves similarly to a combination of a stopwatch and an alarm clock. The event is triggered as soon as the process reaches the activity that is linked to the event. Whatever happens next depends on the event being interruption or non-interrupting.



Conditional event

This type of event reacts to certain conditions. The event is triggered as soon as some condition is satisfied.

In case of a start event, it indicates the start of a process when a business condition becomes true.

In case of an intermediate event, it is used as the flow needs to wait until a business condition is fulfilled. It can be used in the sequential flow to indicate that it is necessary to wait until a business condition is fulfilled.

In case of a boundary event, it indicates an exception flow, which will be activated when the condition is fulfilled.



Signal event

Is used to provide signaling between processes. For a start event, this means that the process is triggered by an external signal, for example, the signal that a new customer was created in the ERP system.

In case of an intermediate or boundary event, the event awaits a signal.

For an end event, a signal is sent that is received either externally, or by a linked catching signal within the process model.



Link event

This is a mechanism for linking two parts of a process. Link events can be used to create loops in the process or to avoid long sequence flows. It can only be used for intermediate events, one of which is the throwing event and the other is the catching event. The throwing link event can be linked to the catching link event via the link menu.



Error event

This type of event is used for error handling.

A start error event catches defined errors (catching).

A boundary error event catches and processes defined errors. For an intermediate event, this characterization can only be used as an interrupting boundary event.

In case of an end error event, it indicates that a defined error is generated (throwing) when the process is ended.



Escalation event

This is a variation of the error event.

In case of a start event, the event reacts to escalation to another role in the organization. This event type is only used in an event sub-process.

For an intermediate event, the catch and throw behavior is equal to the behavior of an error event, but with the following differences:

  • The boundary event is non-interrupting by default.
  • Escalation does not mean an error, but merely some additional processing that is triggered during a process activity.

In case of an end event, the catch and throw behavior is equal to that of an error event, the only difference being that in case of escalation the process or sub-process will not be terminated if one or more parallel paths are still active.



Cancel event

This indicates that a transaction should be canceled immediately, and provides a response (trigger).

For an intermediate event, the cancel event is only used for boundary events attached to a transaction.

In case of an end event, the cancel event is a variant of an error event. The cancel event is only used within transactional sub-processes and is always interrupting.



Compensation event

For an end event, this indicates that the process was finished and that compensation is required.

For an intermediate event in the subsequent flow of a process, this indicates that compensation is required (throwing). In case of use on the boundary of a task, it indicates that this task will be compensated upon activation of the event (catching).



Terminate event

Can only be used for an end event. Initiates the immediate termination of all activities in a process.



none

Multiple event

Can be used for all event types.

For a start event, this characterization indicates that multiple events can potentially start the process. The occurrence of just one of these events is required to actually trigger the start of the process.

For an intermediate and boundary event, this characterization means that multiple triggers are assigned to the event.

In case of an end event, this characterization indicates that many results are possible after completion of the process. All of these results need to be achieved.



none

Parallel multiple event

Only start, intermediate and boundary events can be characterized as parallel multiple event.

For a start event, this characterization indicates that multiple events can potentially start the process. The occurrence of all of these events is required to actually trigger the start of the process.

In case of a catching intermediate event and a boundary event, this characterization indicates that multiple triggers are assigned to the event.



Gateway types

Symbol

Type + description

none or

Exclusive gateway

In case of a split, only one of the outgoing flows is to be followed, based on some condition. A split of this kind is also called an XOR-split.

An exclusive gateway can be displayed in two ways, with and without an X in it.

In case of a join, the flow continues after one of the flows has entered the gateway. A join of this kind is also called an XOR-join.


     


Inclusive gateway

In case of a split, one or more of the exiting flows will be selected for continuation of the process, depending on the conditions that are defined for the gateway. A split of this kind is also called an OR-split.

In case of a join, the corresponding incoming flow of all selected flows must have entered the gateway before the process is allowed to continue. A join of this kind is also called an OR-join.



Parallel gateway

In case of a split, all outgoing flows are to be followed in parallel. A split of this kind is also called an AND-split.

In case of a join, all entry flows need to have entered the gateway before the process is allowed to continue. A join of this kind is also called an AND-join.



Event-based gateway

Represents a point in the process where the flow splits up. All the available alternatives are based on the events that occur at that point in the process. This is always followed up by incoming events or catching tasks.



Complex gateway

This is a complex split or join that cannot always be defined by gateways. It is used for all types of splits and joins that cannot be represented by the default types of gateways.



Resource role types

A resource role is used to define resources that perform an activity or are responsible for an activity. With the available types, resource roles can be characterized in more detail from general to more specific.

Symbol

Type + description

Performer

A resource role of type performer is the most general characterization. The performer is the resource that performs the activity or is responsible for it. The performer can be specified in the form of a specific individual, a group, an organization role or position, or an organization.



Human performer

With the human performer type, you explicitly specify that the resource is a person.



Potential owner

A potential owner is a specialization of human performer. A resource role of type potential owner represents the person who is responsible for an activity and can decide to start the activity.



Markers

Markers show the output behavior of a task. The markers listed below can be present for a task. Some of these markers are documented using a control that is available for the task.

Symbol

Name + description

Open

This icon appears in a sub-process or transaction, after adding details within the object and subsequently clicking the Collapse control in order to hide the details. Upon clicking the plus icon, the details will be shown in a separate diagram.

Jump to called element

For a call activity, this icon appears after linking the call activity with a process using the Set called element control. Upon clicking the plus icon, the called process will be shown in a separate diagram. From a call activity, it is also possible to call a global task, but no plus icon will appear in that case.



Loop

Indicates that the (choreography) task, sub-process, sub-choreography or call activity is a repeated activity, of type standard loop. This is configured using the Toggle loop control.



Multi-instance - parallel

Indicates that the (choreography) task, sub-process, sub-choreography or call activity is a repeated activity, of type multi-instance - parallel. This is configured using the Toggle loop control.



Multi-instance - sequential

Indicates that the (choreography) task, sub-process, sub-choreography or call activity is a repeated activity of type multi-instance - sequential. This is configured using the Toggle loop control.



Ad hoc

Indicates that a sub-process is ad hoc. This is configured using the Toggle ad hoc control. An ad hoc sub-process comprises a number of embedded inner activities and is executed in a more flexible order than normal processes.



Compensation

Indicates that a task is a compensation task. This is configured using the Toggle compensation control. A compensation task is an activity that is used as an alternative in case of failure during the execution of another (normal) activity.