
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 ![]() | Circle with a double border ![]() | Circle with a bold border ![]() |
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 | ![]() |
| Simple start event, self-triggered | Customer visits an e-commerce website. |
Message | ![]() |
| Triggered by a message | The system receives a successful payment notification from the payment system. |
Timer | ![]() |
| Triggered after a specific time interval | The process automatically starts after 24 hours. |
Timer | ![]() |
| Similar to above | |
Escalation | ![]() |
| 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 | ![]() |
| Similar to above | |
Conditional | ![]() |
| Triggered based on a condition | The process starts if the customer chooses the "Cash on Delivery" payment method. |
Conditional | ![]() |
| Similar to above | |
Error | ![]() |
|
| For example, invalid card payment -> Error event |
Compensation | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| Similar to above | |
Multiple | ![]() |
| 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 | ![]() |
| Similar to above | |
Parallel Multiple Event | ![]() |
| 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 | ![]() |
|
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 | ![]() |
| 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 | ![]() |
|
| |
Message | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| The "Prepare Goods" activity has a Link Catching Event waiting for the "Order Paid" Link carrying detailed order information before starting preparation. | |
Link | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| 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 | ![]() |
| 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 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 | ![]() |
| ||
Signal | ![]() |
| 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: 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 | ![]() |
| ||
Multiple | ![]() |
| 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 | ![]() |
| 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 | ![]() |
|
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.
Comments