Overview

Events in BPMN represent things that happen. A process can react to events (catching event) as well as emit events (throwing event). For example, a catching message event makes the token continue as soon as a message is received. The XML representation of the process contains the criteria for which kind of message triggers continuation.

Events can be added to the process in various ways. Not only can they be used to make a token wait at a certain point, but also for interrupting a token's progress.

Currently supported events:

• None events
• Message events
• Timer events
• Error events
• Escalation events
• Terminate events
• Link events
• Signal events
• Compensation events

note

Not all the events are supported yet. For a complete overview of supported events, refer to the BPMN coverage.

Events in general

Events in BPMN can be thrown (i.e. sent) or caught (i.e. received), respectively referred to as throw or catch events (e.g. message throw event, timer catch event). The distinction is about which side of the event the process is on: a throw event is something the process itself actively does as part of its own execution (for example, sending a message or raising an escalation); a catch event is something the process passively waits for, coming from outside the process (for example, a message arriving, or a timer elapsing).

Additionally, a distinction is made between start, intermediate, and end events:

• Start events (always catch events) react to something external to begin the process or subprocess — a process can't start itself.
• End events (always throw events) are the process's own final action, such as sending a message or signaling that an error occurred, and denote the end of a particular sequence flow.
• Intermediate events can go either way: an intermediate throw event performs an action as part of the process's execution, while an intermediate catch event pauses the process and waits to react to something external.

Intermediate catch events can be inserted into your process in two different contexts: normal flow, or attached to an activity, and are called boundary events.

Intermediate events

In a typical flow, an intermediate throw event executes its event (e.g. send a message) once the token has reached it. Once complete, the token continues to all outgoing sequence flows (1).

An intermediate catch event, however, stops the token and waits until the event it is waiting for occurs, at which point execution resumes and the token moves on (2).

Boundary events

Boundary events provide a way to model what should happen if an event occurs while an activity is active. For example, if a process is waiting on a user task to happen which is taking too long, an intermediate timer catch event can be attached to the task, with an outgoing sequence flow to notification task, allowing the modeler to automate and sending a reminder email to the user.

A boundary event must be an intermediate catch event, and can be either interrupting (1)or non-interrupting (2). Interrupting means that once triggered, before taking any outgoing sequence flow the activity the event is attached to is terminated. This allows modeling timeouts where we can prune certain execution paths if something happens (e.g. the process takes too long).