BPMN Notation: Events

Jan 49 min read

1. Definition

Events represent occurrences within a BPMN process flow. There are three main types:

Start Event: Defines the starting point of a process.
Intermediate Event: Defines a transition or interruption point within a process.
End Event: Defines the end point of a process.

	Start Event	Intermediate Event	End Event
Purpose	Defines the starting point	Defines a transition/interruption point	Defines the end point
Quantity	Only one per flow	Can have multiple per flow	Only one per flow
Trigger Type	Always self-triggered	Depends on conditions	Self-triggered with condition
Shape	Circle with a single border Start event	Circle with a double border Intermediate event	Circle with a bold border End event

2 Event marker

Like activities, events can contain markers to provide additional information about the event.

2.1 Start event

There are three types of start events based on their purpose and behavior:

Standard: The most basic type for a process.
Event Sub-process Interrupting: A start event used for a sub-process. This event type interrupts the main flow of the process to trigger the sub-process.
Event Sub-process Non-interrupting: Similar to the interrupting type, this event is used for a sub-process. However, it doesn't interrupt the main flow but runs in parallel with it.

Marker	Icon	Type	Meaning	Example
None		Standard	Simple start event, self-triggered	Customer visits an e-commerce website.
Message		Standard Event sub-process interrupting	Triggered by a message	The system receives a successful payment notification from the payment system.
Timer		Standard Event sub-process interrupting	Triggered after a specific time interval	The process automatically starts after 24 hours.
Timer		Event sub-process non-interrupting	Similar to above
Escalation		Event sub-process interrupting	Escalation triggers a critical error handling process - an error that requires a separate process to handle	Payment system error, requiring the activation of an external exception handling process.
Escalation		Event sub-process non-interrupting	Similar to above
Conditional		Standard Event sub-process interrupting	Triggered based on a condition	The process starts if the customer chooses the "Cash on Delivery" payment method.
Conditional		Event sub-process non-interrupting	Similar to above
Error		Event sub-process interrupting	Used for common errors that can be handled within the main process.	For example, invalid card payment -> Error event
Compensation		Event sub-process interrupting	Starts a compensation process, as mentioned in 1.1.	For example, the "Payment" action has a Compensation Event. If the payment fails, the Compensation Event is triggered.
Signal		Standard Event sub-process interrupting	Triggered by a signal	The system receives a signal from an external service. For example, MoMo automatically creates a transaction when there's a payment request from an e-commerce website.
Signal		Event sub-process non-interrupting	Similar to above
Multiple		Standard Event sub-process interrupting	Triggered by any of the listed conditions	The process starts when the customer chooses to pay for an order, or pay an electricity bill, or a phone bill, etc.
Multiple		Event sub-process non-interrupting	Similar to above
Parallel Multiple Event		Standard Event sub-process interrupting	Similar to Multiple Event, but all events must be triggered simultaneously.	For example, in an order processing process, the Parallel Multiple Event is only triggered when all three events "Payment Confirmation," "Inventory Check," and "Packaging" occur together.
Parallel Multiple Event		Event sub-process non-interrupting

2.2 Intermediate event

Like start events, intermediate events are also divided into different types based on their purpose:

Catching: This type of event waits for an event to occur within an activity. When the triggering event is caught, it interrupts or pauses the activity and can redirect the process flow.
Throwing: This type of event sends a message, signal, or triggers another event. It is placed inside or on the boundary of an activity. When the activity is completed, this event is triggered and sends the necessary data.
Boundary: This type of event is attached to the boundary of an activity, allowing for handling errors or external events that may affect that activity. It occurs regardless of whether the activity is running, has failed, or has been completed.
- Boundary events are divided into two types:
  - Boundary Interrupting: Interrupts the activity when the event occurs.
  - Boundary Non-interrupting: Does not interrupt the activity; runs in parallel with the activity when the event occurs.

Marker	Icon	Type	Meaning	Example
Message		Catching Boundary interrupting	When an event is received and matches the Message Event, it triggers the event.	The "Payment Confirmation" activity has a Message Event waiting for a confirmation message from the payment system. When the message is received, the Message Event is triggered, and the activity continues to the next step.
Message		Boundary non-interrupting	Similar to above. Does not interrupt the activity but runs in parallel.
Message		Throwing	When the activity is completed, a "message" is sent.	The order is successfully paid, the Message Event sends a notification email to the customer.
Timer		Catching Boundary interrupting	Starts another activity/flow when the time condition is met. Interrupts the flow when triggered.	For the "Prepare Order" activity, after 4 hours, trigger the order cancellation event and notify the customer of order failure.
Timer		Boundary non-interrupting	Similar to above. Does not interrupt the activity but runs in parallel.	For the "Prepare Order" activity, after 2 hours, trigger the event to send a notification to the customer that the order is still being prepared. The "Prepare Order" activity continues to occur.
Escalation		Boundary interrupting	Triggers when a serious event occurs within an action. Interrupts the flow when triggered.	The "Prepare Order" activity, when encountering an incident, will trigger the incident handling flow, cancel the order, and refund the customer.
Escalation		Boundary non-interrupting	Similar to above. Does not interrupt the activity.	The "Prepare Order" activity, when encountering an incident, will trigger the incident verification flow and send a notification to the customer about the order status. The order is not canceled.
Escalation		Throwing	Usually attached within the process (boundary escalation is attached to an action). Often triggered by conditions through a gateway.	The "Order Payment" activity has an OR gateway (Exclusive Gateway) as output: Payment successful, Payment failed, Payment error. In case of a payment error, it can trigger an escalation event for error handling.
Conditional		Boundary interrupting	Interrupts the running activity when a specific condition is met. Redirects the process flow to a new path defined by the event.	The "Payment" activity has a Conditional Boundary Interrupting Event that checks the delivery status. If the delivery fails, the event is triggered, interrupting the activity and redirecting to the refund processing flow.
Conditional		Boundary non-interrupting	Similar to above. Does not interrupt the activity when triggered.	The "Process Order" activity has a Conditional Boundary Non-Interrupting Event that checks inventory levels. If the stock is running low, the event updates the order status to "Low Stock Warning" but does not interrupt the activity.
Link		Throwing		The "Prepare Goods" activity has a Link Catching Event waiting for the "Order Paid" Link carrying detailed order information before starting preparation.
Link		Catching	Paired with a Link Throwing Event. Used to start an event sent from the Link Throwing Event below.	The "Payment Confirmation" activity has a Link Throwing Event that sends payment data and order ID to the "Prepare Goods" activity through a Link named "Order Paid."
Error		Boundary interrupting	Identifies and handles errors that occur in a specific activity. Always interrupts the activity when triggered. Multiple Error Boundary Interrupting Events can be used for an activity to handle different types of errors.	The "Prepare Goods" activity encounters an out-of-stock error, sends an email notification to the customer or customer service, and updates the order status.
Cancel		Boundary interrupting	Allows for canceling a running activity based on a defined condition. Always interrupts the activity when triggered.	The "Payment" activity has a "Cancel Payment" event, triggering a cancellation process including: confirming with the customer, refunding, updating the status, etc.
Compensation		Boundary interrupting	Represents a compensation event that is triggered if an error or unexpected event occurs in an activity.	Online payment process: During online payment, if the transaction fails due to a system error or card error, the interrupting compensation event is triggered. The process will automatically refund the customer and notify the technical department to handle the error.
Compensation		Throwing	Usually used to initiate the execution of predefined compensation steps. It can be triggered by an event or error occurring in the process, or by a manual decision from the user.	Warranty claim processing: After receiving a warranty claim, if the product is determined to be faulty, the "Compensation" event is triggered. Compensation might include repairing or replacing the product for the customer.
Signal		Catching Boundary interrupting	Catching signals usually come with throwing signals. This event is used to define a point in the process where an activity will listen and respond to a specific signal. Boundary Interrupting Signal is used to interrupt an executing activity and start performing predefined actions when the signal is received.	Order processing: After the customer places an order, the system sends a signal to the "Process Order" activity. The "Process Order" activity will receive the signal and start executing the order processing steps.
Signal		Throwing
Signal		Boundary non-interrupting	Similar to Boundary Interrupting Signal. Does not interrupt the flow when triggered.	The "Process Order" activity has a "Update Order Information" signal event triggered when an external event occurs, such as a change of address or delivery information. The "Process Order" activity does not need to stop but continues to run while the order is updated.
Multiple		Catching Boundary interrupting	Catching: Defines a point in the process where multiple input events can occur. Only the first occurring event triggers the process. The remaining events are ignored. Essentially, the catching event "catches" and processes whichever event occurs first. Boundary Interrupting: Similar to catching, however, when one of the preconfigured events occurs, it interrupts the executing activity and redirects the flow to the branch created by that specific event.	Example with the "Process Order" activity: There can be multiple events such as: Cancel order, Update delivery address, Change payment method. Catching event: Cancel order: Activates the "Cancel Order" subprocess and interrupts the "Process Order" activity. Update delivery address: Activates the "Update Address" subprocess in parallel with order processing. Change payment method: Activates the "Change Payment Method" subprocess in parallel with order processing. Boundary Interrupting: Any triggered event: Interrupts the "Process Order" activity and redirects to the corresponding branch (Cancel Order, Update Address, Change Payment Method). Boundary Non-Interrupting: Any triggered event: Activates the corresponding subprocess in parallel with order processing.
Multiple		Boundary non-interrupting
Multiple		Throwing	Is an event type used to initiate multiple events simultaneously. When a Multiple Event Throwing is triggered, all events associated with it will be initiated concurrently.	The "Approve Order" activity, when triggering a Multiple Event Throwing, will trigger two actions: Send an email notification to the customer about the order status. Send an SMS message to the customer about the order status.
Parallel Multiple		Catching Boundary interrupting	Similar to Multiple Event, but with Parallel Multiple, all events associated with it must occur. Catching: Listens for multiple events simultaneously. The process only continues when all events have been triggered. Parallel Multiple Event Boundary Interrupting: When all events are triggered, it immediately interrupts the current activity and redirects the process. Parallel Multiple Event Boundary Non-interrupting: When all events are triggered, they trigger subprocesses/activities in parallel with the current activity. Does not interrupt the flow.	"Process Order" process: Events: The system receives an order from the customer. The system checks the inventory. The system checks the payment. Parallel Multiple Event Catching: Waits for all events to be triggered (order received, inventory available, payment successful). After all events are triggered, the process moves to the "Prepare for Delivery" step. Parallel Multiple Event Boundary Interrupting: Attached to the "Process Order" action, triggered when all of the following events occur: "Out of stock" & "No additional stock." Stops the "Process Order" action and redirects to the cancel order flow/action. Parallel Multiple Event Boundary Non-interrupting: Attached to the "Process Order" action, triggered when all of the following events occur: "Out of stock" & "Additional stock available." Does not stop the "Process Order" action. Triggers an additional "Replenish Stock" flow that runs in parallel with the "Process Order" action.
Parallel Multiple		Boundary non-interrupting

2.3 End event

Unlike Start or Intermediate Events, End Events have only one type: Standard, represented by a circle with a bold border.

End events also use markers to provide additional information about the event.

Marker	Icon	Meaning	Example
None
Message		Ends the process by sending a notification message. Often used to trigger another process or communicate with external systems.	Send an email notification to the customer upon order completion.
Escalation		Ends an escalation event triggered by a start or intermediate event.	The system cannot connect to the payment gateway.
Error		Ends an error event triggered by a start or intermediate event. Or ends the process due to a technical error.	Error updating the order.
Cancel		Immediately ends the process and cancels all running activities. Used when the process does not deliver value or violates regulations.	The customer cancels the order unexpectedly.
Compensation		Ends the process and creates a compensation activity to "undo" the steps taken in the process.	Update the inventory quantity if the customer cancels an already paid order.
Signal		Ends the process and emits a signal.	Emits a "New Order" signal to trigger the warehouse to check and pack the product.
Multiple		Ends the process with multiple possible outcomes.	The order processing result can be "Delivery successful," "Customer canceled," or "Unsuccessful."
Terminate		Immediately ends the entire process, including sub-processes and parallel processes. Used when a critical error occurs, and stopping the entire process is mandatory.	If a critical software error cannot be resolved in a short time, the Terminate End Event will be triggered.

These are all the events currently available in BPMN. Events are a crucial part of BPMN, serving as markers for the start, end, or change of direction within a process. Understanding the different event types and how to use them will help you build accurate and effective BPMN models.