An Event is any element in a BPMN-based Process or Plan model that triggers or terminates the workflow, thus modifying the execution pace or causing a flow change.

Based on the position and function in the workflow, the following types events are available:

Start Events trigger workflow execution by creating contexts and producing tokens.
Intermediate Events delay processes based on events or handle an event produced in an activity if used as a boundary element.
End Events consume the incoming token.

Start Events

A Start Event indicates where a particular workflow starts. When triggered, it creates the context for the element it is in, that is a process, plan, or subprocess, and, in this context, produces a token, which leaves through its outgoing flow.

A Start Event has no incoming flow and only one outgoing Normal Flow.

In Plans of Goal-based Processes and Sub-Processes, its None Start Event is triggered when the Plan becomes running. A Plan can contain only a None Start Event.

While a model instance is running, any Start Events in its BPMN-based Process create a Process instance when their trigger occurs: if there is a Condition Start Event and its condition is true, the event is triggered when the model instance starts and whenever the condition becomes false and true again as long as the model instance is running.

Start Events with triggers are allowed in BPMN-based processes and inline event sub-processes:

In a BPMN-based process: Start Events whose triggers occurred, are triggered when the model instance is created. Each Start Event creates its Process instance in the Model instance. If the trigger occurs again while the process instance is running, the respective Start Event creates a new Process instance.
In an [inline event sub-process], if the trigger occurs at any time while the parent process instance or sub-process instance is running, the events are triggered: they create an instance of their sub-process and produce a token. Note that the inline event subprocess can be also a reusable sub-process so the Start Events can be in the referenced Process.

None Start Events

A None Start Event is triggered when its parent context is created. It does the following depending on its location:

When in a BPMN-based Process, it creates the context of the process instance and produces a token when the model instance becomes running;
When in a Sub-Process: it creates the context of the subprocess and produces a token when the sub-Process is triggered, that is, it receives a token via its incoming flow or, if the sub-process does not have an incoming flow, at the moment it is triggered.
Plan, once the Plan becomes running, the None Start Event of the Plan Model is triggered.

None Start Event

Conditional Start Events

A Conditional Start Event defines a boolean condition expression as its trigger and starts a BPMN-based Process or an inline-event subprocess:

When in a BPMN-based Process, the event creates and triggers an instance of the process:
- when its condition is true at model instantiation
- when the condition, previously evaluated to false, becomes true while process instance is running.
When in an inline-event subprocess, the event creates and triggers an instance of the sub-process
- when its condition is true at process instantiation
- when the condition, previously evaluated to false, becomes true while process instance is running.

Note that the condition cannot reference local context since the context does not exist at the moment when it is evaluated.

Conditional Start Event

Conditional Start Event Attributes

Condition evaluated when the event is triggered. If true, the event produces a token.

Signal Start Events

A Signal Start Event creates the context of a BPMN-based Process or an inline-event subprocess and produces a token when it receives a Signal that passes through the Filter.

Signal Start Event

Filter: filter for the expected Signal object
Signal: reference where to store the received signal value

Timer Start Events

A Timer Start Event defines a timer trigger. It starts a BPMN-based Process or an inline event subprocess:

When in a BPMN-based Process, the event creates and triggers an instance of the process when the point in time define by its Timer trigger occurs or periodically always when the specified time period elapses while the parent model instance is running.
When in an inline-event subprocess, the event creates and triggers an instance of the sub-process when the point in time define by its Timer trigger occurs or periodically always when the specified time period elapses while the parent process instance is running.

If the specified point in time has already occurred, the event is triggered immediately when the parent context is instantiated. If both the Date and the Period property are defined, the start event is triggered periodically with the period countdown starting from the Date value. If the duration is null or negative, the start event is executed only once.

Timer Start Event Notation

Timer Start Event

Timer Start Event Attributes

Date: date when the event triggers execution, that is, produces a token
Period: periodicity of process instance triggering

Escalation Start Events

An Escalation Start Event creates the context of an inline event subprocess and produces a token when it receives an Escalation object while its parent instance is running (parent can be either a process instance or a sub-process instance if the sub-process is nested in another sub-process).

In other than an Inline Event Sub-Process, the event is ignored.

Escalation Start Event

Escalation Start Event Attributes

Filter defines the escalation codes of accepted Escalation objects. If the object does not have any of the defined codes, it is ignored. If no codes are defined, any Escalation object triggers the event.
Escalation is the reference to a local or global context (for example, a variable or a variable field) that will store the received Escalation object.
Escalation code reference: Event consumes only escalations with the defined escalation code (if the escalation code is not specified then the Event accepts all escalations).

Error Start Events

An Error Start Event triggers its flow when it receives an Error object. You can use it only as a start event of an Inline Event Sub-Process: When the parent of the sub-process throws an error and the error code matches a code in the Error Code Filter of the Error Start Event, the event creates the context of the inline event sub-process and produces a token.

The parent can be either a process instance or a sub-process instance if that the sub-process is nested in another sub-process.

In other than an Inline Event Sub-Process, the event is ignored.

Error Start Event

Error Start Event Attributes

Error Code Filter defines the filter that returns the expected errors (only error events from the Error reference that meet the filter criterion trigger the start event).
Error Code is the reference to a local or global context (variable or a variable field) that will store the received error.

Intermediate Events

An intermediate event process element handles a predictable event that can occur during workflow execution, such as, an error, timeout, breached condition, etc. When such event occurs, the event produces a token, which takes the outgoing flow of the event.

The scope the events listen to is defined by where they are placed:

on the boundary of an Activity: If the activity is Alive and the event occurs, the outgoing flow of the Intermediate Event is taken.

Note: If a boundary event is attached to a multi-instance Activity, all the instances of the Activity are interrupted when the Event is triggered.

When the Intermediate Event on an activity is triggered, the activity can either continue or terminate. This depends on the interruptibility property of the Intermediate Event:
- If the event is interrupting, the activity is deactivated when the event is triggered.
- If the event is non-interrupting, the activity continues its execution: note that if the event occurs again while the Activity is alive, the boundary event is triggered again.
flow object with one incoming and one outgoing flow: the event is triggered when the flow reaches the event. Once the event occurs, the execution continues via the outgoing flow of the Intermediate Event.
flow object with no incoming and one outgoing flow: the event is triggered whenever the event condition occurs while its context is running.

Timer Intermediate Events

A Timer Intermediate Event either temporarily delays a workflow or triggers a workflow at a moment in time:

If placed in a workflow as a flow object with one incoming and one outgoing Flow, the event pauses the workflow execution for the defined time period or until the defined point in time has occurred.

Note: The target element of a Sequence Flow leaving a Gateway must not be a Timer Intermediate Event.
If placed on an Activity border, as soon as the Activity becomes active, the countdown of the time period is triggered (or the event is waiting for the point in time to occur).

When the time elapses and the Activity is still active, the timer event triggers its outgoing flow. If the Activity finishes before the time elapses, the event is not used (Flow leaving the Activity is taken).

There can be several Timer Intermediate Events on one Activity: whichever happens first is used. Similarly, also if an event defines both the duration and the date whichever happens first is used.

The event must define its time event either as a time duration—for example, 24 hours—or as a point in time, for example, a date: 2022-2-2) in one of its properties:

Date: date when the event triggers execution, that is, produces a token
Duration: periodicity with which the event triggers execution, that is, produces a token

Non-Interrupting Timer Intermediate Event

Interrupting Timer Intermediate Event

Error Intermediate Events

An Error Intermediate Event serves to define a workflow that is taken after an Activity produces an error: it explicitly produces an error or it ends with an Error End Event.

The element is placed on boundaries of Activities, that is, Tasks or Sub-Process. An Activity can have multiple Error Intermediate Events attached to its boundary.

An Error Intermediate Event can define a set of errors it may consume. The errors are identified by their error code. Once the event catches one of the error codes, its outgoing Flow is taken. If no error code is specified (null), the Error Intermediate Event catches any Error produced in its child contexts unless it is processed by other Error Intermediate Event, which explicitly specifies the error code.

If there are several Error Intermediate Events attached to an Activity, the Error is caught and processed by the Error Intermediate Event with the priority depending on the way its error codes are defined:

only the error code of the particular error;
set of error codes including the particular error code;
no particular error code.

Non-Interrupting Error Intermediate Event

Interrupting Error Intermediate Event

Error Intermediate Event Attributes

Error Code Filter defines the filter that returns the expected errors (only error events from the Error reference that meet the filter criterion trigger the event).

If no filter is defined of returns null, the event catches all errors.
Error Code is the reference to a local or global context (variable or a variable field) that will store the received error.

Cancel Intermediate Events

A Cancel Intermediate Event is an event that handles a Cancel End Event with the aim to cancel the actions of a Transaction Sub-Process.

Hence, it can be attached only to a boundary of a Transaction Sub-Process that contains a Cancel End Event. When the Sub-Process finishes with the Cancel End Event, the outgoing flow of the Cancel Intermediate Event attached to its boundary is taken.

Non-Interrupting Cancel Intermediate Event

Interrupting Cancel Intermediate Event

Conditional Intermediate Event

A Conditional Intermediate Event is an intermediate event which checks a particular condition and is triggered when the condition becomes true:

If placed on an Activity boundary, the condition is checked continuously while the Activity is active or running. At the moment the condition becomes true, the execution of the Activity becomes interrupted and the Flow leaving the Conditional Intermediate Event is taken.

Note: There can be one or multiple Conditional Intermediate Events attached to one Activity.

If used in a workflow as a flow element with an incoming and outgoing flow, when the token reaches the Event, it is held until the condition becomes true.

Non-Interrupting Conditional Intermediate Event

Interrupting Conditional Intermediate Event

Throw Signal Intermediate Event

A Throw Signal Intermediate Event produces a Signal that can be caught by Start Signal Events and Signal Intermediate Events of particular model instances.

It can be used only as a workflow element with one incoming and one outgoing Flow.

When reached during execution, it sends the defined Signal to the defined model instances. If no model instance is defined, the Signal is sent to its parent model instance. In the target model instances, it is consumed by all running Catch Signal Intermediate Events waiting for the Signal at the given moment and the Signal Start Events.

The Throw Signal Intermediate Event has to define the signal and the target model instances:

Model instances defines the IDs of model instances to which you want to send the Signal.
Signal value defines the Signal value.

Non-Interrupting Throw Signal Intermediate Event

Interrupting Throw Signal Intermediate Event

Catch Signal Intermediate Event

A Catch Signal Intermediate Event is triggered when it catches a Signal. Subsequently it produces a token which takes its outgoing Flow.

It can be either attached to a boundary of an Activity or used as a workflow element with one incoming and one outgoing Normal Flow. When active it waits until it has receives a Signal.

It can define a filter for the Signals it acceptst; if the received signal does not meet the defined filter criteria, it does not send a token.

The Catch Signal Intermediate Event cannot handle Signals of the type Reference, goal, Plan, or ModelInstance. Catching such signals causes a runtime exception.

Catch Signal Intermediate Event defines:

Filter: filter of the accepted Signal
Signal: reference to a storage, where the caught signal is stored

Non-Interrupting Catch Signal Intermediate Event

Interrupting Catch Signal Intermediate Event

Throw Escalation Intermediate Event

A Throw Escalation Intermediate Event is an Event which sends an Escalation object when triggered.

It can be used only as a workflow object with one incoming and one outgoing flow. When reached during execution, it sends the defined Escalation object, which is propagated throughout its context and up to higher contexts either until consumed by a Start Escalation Event or a Catch Escalation Intermediate Event or until no higher context is available.

Throw Escalation Intermediate Event Attributes

Escalation code defines the escalation code sent with the escalation object.
Escalation defines the payload of the Escalation object.

Important: It is not possible to filter according to information in payload. You can use only the escalation code.

Catch Escalation Intermediate Event

A Catch Escalation Intermediate Event is a boundary intermediate event that catches and consumes an Escalation object that was thrown in its Activity and meets the filter criterion, and produces a token. It can be used only as a boundary element on an Activity and with an outgoing Normal Flow.

The event is active while the Activity is active. When the Escalation object is thrown in the Activity or its child contexts, the boundary Catch Escalation Intermediate Event consumes the Escalation object and produces a token which takes its outgoing Flow. Note that just like other boundary Intermediate Events, it can be non-interrupting or interrupting.

Catch Escalation Intermediate Event must define a reference object, where the object is stored. It can optionally define a filter definition: if the received Escalation object does not meet the filter criteria, it is ignored.

Catch Escalation Intermediate Event Notation

Non-Interrupting Catch Escalation Intermediate Event

Interrupting Catch Escalation Intermediate Event

Catch Escalation Intermediate Event Attributes

Filter contains the escalation codes of accepted Escalation objects.
Escalation defines a reference to a storage, where the caught escalation signal is to be stored.
Escalation code reference: Event consumes just escalations with the defined escalation code (if the escalation code is not specified then the Event accepts all escalations).

End Events

An End Event ends a workflow (consumes a token).

A workflow has one or multiple End Events and one or multiple Sequence Flows can enter an End Event. No outgoing Flow is allowed.

There are multiple types of End Events, which differ by the actions they perform when an execution flow enters the end events, that is, how they behave when they consume a token.

Simple End Events

A Simple End Event is the basic end Event type which consumes the incoming token; other tokens in the workflow remain uninfluenced. The particular workflow is finished successfully if it does not contain any other tokens.

Simple End Event Notation

Simple End Event

Terminate End Event

When a workflow reaches a Terminate End Event, all tokens in the namespace are consumed and the execution ends successfully.

If there are other activities in the workflow, they are instantly terminated (as soon as a Terminate End Event consumes one token, any other tokens in the workflow are discarded).

Terminate End Event Notation

Terminate End Event

Error End Events

A Error End Event is an end event that implement error handling on a workflow end. The actions when triggered depend on the type of the parent namespace of the End Event. When a token enter an Error End Event, enters an Error End Event the following happens:

if in a Sub-Process:

The End Event generates an error with the respective Error Code (see Error) and the workflow is finished. The error is distributed gradually to higher namespaces and can be caught by an Error Intermediate Event contained in any parent namespace as to trigger a compensation process (see Error Intermediate Event).

Plan Models

If a Plan Model ends with an Error End Event, the Plan fails (becomes Failed).
BPMN-based Processes

If a BPMN-based Process instance finishes with an Error End Event, the last transaction is rolled back and an exception is created.

Error End Event

Error End Event Attributes

Error code defines the error code to be sent.

Cancel End Events

A Cancel End Event is a special End Event which ends a Transaction Sub-Processes.

When a token enters a Cancel End Event and the parent Transaction Sub-Process has no Cancel Intermediate Event attached, the last transaction is rolled back.

If there is a Cancel Intermediate Event attached to the parent Sub-Process, the Sub-Process execution fails (the Sub-Process becomes Interrupted) and the outgoing Flow of the attached Event is taken.

Cancel End Event Notation

Cancel End Event

Throw Escalation End Events

When a workflow ends with a Throw Escalation End Event, the event generates an Escalation object with the respective code and the workflow finishes. The escalation is distributed gradually to higher context and can be caught by a Catch Escalation Intermediate Event or Escalation Start Event in any parent context.

Escalation End Event Notation

Escalation End Event

Escalation End Event Attributes

Escalation code defines a code sent with the escalation object that serves as the escalation identifier.
Escalation defines the payload of the Escalation object.

Note: It is not possible to filter according to information in payload. You can use only the escalation code.

No Exit End Events

A No Exit End Event is an end event that consumes a token in the workflow of an Inline Event Sub-Process without triggering the Sub-Process' outgoing Flow: no token for any outgoing Flow if present is produced but the Sub-Process execution finishes with success.

If a Process with such an event is used by a Reusable Inline Event Sub-Process which is not used as part of the workflow, that is, it does not have an outgoing Flow, the No Exit End Event behaves as a Simple End Event.

No Exit End Event