BPMN Events: A Beginner’s Guide

In BPMN 2.0, an event represents something that happens during a business process. Events can start a process, interrupt or influence its flow, or indicate how a process ends.

Examples include:

• An order is received

• A timer expires

• A payment is completed

• A message arrives

• An error occurs

• A customer cancels a request

Events are shown as circles in BPMN diagrams.

1. The three basic event positions

Start events

A start event indicates how a process begins.

Example:

Message received → Start process → Check order

A process may start because:

• Someone submits a form

• A scheduled time arrives

• A message is received

• A rule becomes true

• Another process signals it to begin

A start event usually has a thin circle border.

Intermediate events

An intermediate event occurs between the start and end of a process.

It can:

• Wait for something

• Send something

• Catch an event

• Throw or trigger an event

• Interrupt an activity

• Delay the process

Example:

Receive order → Wait for payment → Ship order

An intermediate event usually has a double circle border.

End events

An end event indicates how a process finishes.

Examples:

• Order completed

• Request rejected

• Notification sent

• Process failed

• Compensation required

An end event usually has a thick circle border.

Example:

Approve request → Notify customer → End

2. Catching and throwing events

Events can either catch something or throw something.

Catching events

A catching event waits for or receives something.

Examples:

• Wait for a message

• Wait until a timer expires

• Wait for a signal

• Wait until a condition becomes true

Example:

Submit application → [Wait for approval message] → Create account

The process pauses until the message arrives.

Throwing events

A throwing event actively produces or sends something.

Examples:

• Send a message

• Broadcast a signal

• Escalate a problem

• Trigger compensation

Example:

Complete order → [Send confirmation message] → End

The process sends the confirmation and continues or finishes.

A useful distinction is:

Event behavior	Meaning
Catching	Waits for something to happen
Throwing	Causes or communicates something

3. Common BPMN event types

BPMN provides several event definitions. The event symbol normally contains an icon that identifies its type.

None event

A none event has no special trigger.

It is commonly used for:

• A generic process start

• A generic process end

• A point in the process with no specific event behavior

Example:

None start → Review application → None end

Use it when no message, timer, error, or other event is relevant.

---

Message event

A message event represents communication between separate participants, such as:

• A customer and a company

• A supplier and a buyer

• Two departments

• Two independent pools

Examples:

• Receive a purchase order

• Send an invoice

• Receive a shipping confirmation

• Send an approval request

Message start event

Starts a process when a message arrives.

Customer sends order
        ↓
Message start event → Validate order → Process payment

Intermediate message catch event

Waits for a message.

Submit request → Wait for manager response → Continue processing

Intermediate message throw event

Sends a message.

Approve loan → Send approval notification → Archive request

Message end event

Ends the process by sending a message.

Complete shipment → Message end: Send delivery confirmation

A message is generally directed to a specific recipient.

---

Timer event

A timer event represents a date, duration, cycle, or deadline.

Use timer events to model:

• Waiting for 24 hours

• Running a process every Monday

• Starting at a specific date and time

• Escalating after a deadline

• Cancelling an activity after a timeout

Timer start event

Starts a process according to a schedule.

Timer start: Every Monday at 08:00
        ↓
Generate weekly report

Timer intermediate event

Pauses or delays the process.

Send invoice → Timer: Wait 14 days → Check payment

Timer boundary event

Attached to an activity to create a timeout.

Request approval
 └── Timer boundary: 3 days
          ↓
       Escalate request

Timer expressions can represent:

• A fixed date

• A duration

• A repeating cycle

Conceptually:

Date: 2026-10-01T09:00
Duration: P3D       = three days
Cycle: R/P1W        = repeat every week

The exact expression format depends on the BPMN implementation tool.

---

Error event

An error event represents an expected business or technical error.

Examples:

• Payment authorization failed

• Required data is invalid

• External service returned an error

• A transaction cannot be completed

An error event is normally used to model exception handling.

Example:

Process payment
 ├── success → Create receipt
 └── error boundary → Notify customer → End: Payment failed

An error event is typically used with:

• Subprocesses

• Call activities

• Boundary events

• End events

A process usually does not begin with an error event because errors normally occur after processing has started.

---

Escalation event

An escalation event indicates that a situation should be raised to a higher level without necessarily stopping the entire process.

Examples:

• A customer complaint requires supervisor review

• A claim exceeds an employee’s approval limit

• A service-level deadline is approaching

• A low-priority issue becomes urgent

Example:

Handle complaint
 └── Escalation boundary → Supervisor review

Escalation differs from error because it often represents a business concern rather than a technical failure.

---

Cancel event

A cancel event indicates cancellation of a transaction subprocess.

It is mainly used with transaction subprocesses.

Example:

Transaction: Purchase goods
 ├── Reserve inventory
 ├── Arrange payment
 └── Cancel event → Undo reservation and payment steps

A cancel event is different from a general error:

• Cancel means the transaction is being rolled back or cancelled.

• Error means an error condition has occurred.

---

Compensation event

A compensation event performs corrective or rollback work for an activity that has already completed.

Examples:

• Refund a payment

• Release reserved inventory

• Cancel a hotel booking

• Restore a previous configuration

Example:

Book hotel → Charge customer → Confirm trip
                         ↓
                  Compensation: Refund customer

Compensation is not the same as ordinary process reversal. It explicitly models business undo actions.

---

Conditional event

A conditional event waits until a business condition becomes true.

Examples:

• Account balance falls below a threshold

• Inventory becomes available

• Customer reaches a credit limit

• Temperature exceeds a specified value

Example:

Monitor application → Wait until credit score ≥ 700 → Approve loan

A conditional event is useful when the process waits for a rule or state change rather than a message or timer.

---

Signal event

A signal event broadcasts information to multiple participants or processes.

Examples:

• Broadcast a system maintenance announcement

• Notify all branches that a policy changed

• Start several related processes

• Publish an emergency alert

Example:

System maintenance scheduled
        ↓
Signal throw event
   ↙       ↓       ↘
Notify IT  Notify users  Stop integrations

Unlike a message, a signal is not normally directed to one specific recipient. Multiple processes may catch it.

---

Link event

A link event connects two distant points within the same process diagram.

It is useful when:

• The diagram would otherwise require long sequence-flow lines

• You want to connect pages or sections

• A process has a visual continuation elsewhere

A link event consists of:

• A throwing link event

• A catching link event

Conceptually:

Part A: Complete review → Link throw

Part B: Link catch → Prepare contract

Link events are generally used for diagram organization, not communication between independent participants.

---

Multiple event

A multiple event represents more than one possible trigger or result.

Multiple start event

The process can start through any one of several triggers.

Start when:
- Customer submits a form, or
- Employee calls, or
- API request arrives

Multiple intermediate catch event

The process waits for one of several possible events.

Wait for:
- Approval message, or
- Three-day timeout, or
- Cancellation request

The first event that occurs determines the path.

---

Parallel multiple event

A parallel multiple event requires multiple events to occur before the process continues.

Example:

Wait for:
- Manager approval
- Finance approval
- Legal approval
        ↓
Continue contract processing

This differs from an ordinary multiple event:

Event type	Behavior
Multiple	Any one trigger is enough
Parallel multiple	All required triggers must occur

4. Boundary events

A boundary event is attached to the edge of an activity or subprocess. It listens for an event while that activity is running.

Example:

             Timer: 2 days
                  ○
                  │
Receive approval request
                  │
                  ↓

Boundary events are especially useful for:

• Timeouts

• Errors

• Escalations

• Cancellations

• Compensation

• Messages

Interrupting boundary events

An interrupting boundary event stops the attached activity when triggered.

Example:

Process refund
 └── Error boundary event → Log failure → Notify support

If the error occurs, the refund activity stops and the exception path begins.

The boundary event is usually shown with a solid line.

Non-interrupting boundary events

A non-interrupting boundary event starts an additional path but allows the original activity to continue.

Example:

Process insurance claim
 └── Timer boundary: 2 days
          ↓
       Send reminder

The claim processing continues.

The non-interrupting boundary event is usually shown with a dashed line.

Interrupting versus non-interrupting

Type	Effect on original activity
Interrupting	Stops the activity
Non-interrupting	Leaves the activity running

This distinction is one of the most important concepts in BPMN event modeling.

5. Event subprocesses

An event subprocess is a subprocess that starts when a particular event occurs.

It can be:

• Interrupting

• Non-interrupting

Example:

Main process: Handle customer order

Event subprocess: Customer cancellation received
    Receive cancellation → Refund customer → Close order

Interrupting event subprocess

Stops the main process when triggered.

Use it when the event makes the main process unnecessary or impossible to continue.

Example:

Order processing
  └── Cancellation received → Stop order processing

Non-interrupting event subprocess

Runs alongside the main process.

Use it for additional actions that do not stop the main work.

Example:

Order processing
  └── Customer asks for status → Send status update

The order processing continues while the status response is handled.

6. Event-based gateways

An event-based gateway routes the process according to whichever event occurs first.

Example:

Send approval request
          ↓
Event-based gateway
      ↙       ↘
Message     Timer
approval    expires
   ↓           ↓
Continue    Escalate

This is different from a data-based exclusive gateway.

Data-based gateway

Chooses a path based on a condition already evaluated.

Amount > $10,000?

Event-based gateway

Waits for an event to occur.

Approval received or deadline reached?

Use an event-based gateway when the process is waiting for external events, messages, or timeouts.

7. Start, intermediate, and end event examples

Example 1: Online order

Message start: Order received
        ↓
Validate order
        ↓
Process payment
        ↓
Timer catch: Wait for payment confirmation
        ↓
Message throw: Send shipping request
        ↓
End: Order submitted

Possible exception:

Process payment
 └── Error boundary → Notify customer → End: Payment failed

Example 2: Employee leave request

Message start: Leave request submitted
        ↓
Check leave balance
        ↓
Send manager approval request
        ↓
Event-based gateway
     ↙          ↘
Approval      5-day timer
message       expires
   ↓              ↓
Approve       Escalate to HR
   ↓              ↓
Notify        Notify manager
employee      and employee

Example 3: Customer support ticket

Message start: Ticket received
        ↓
Classify ticket
        ↓
Resolve ticket
 └── Timer boundary: 4 hours
          ↓
       Escalate to supervisor
        ↓
Send resolution
        ↓
Message end: Customer notified

Example 4: Subscription cancellation

Message start: Cancellation request received
        ↓
Verify customer
        ↓
Cancel subscription
        ↓
Compensation: Refund unused balance
        ↓
Message end: Cancellation confirmation sent

8. Events compared with activities and gateways

BPMN elements have different purposes:

Element	Purpose	Example
Event	Something happens	Payment received
Activity	Work is performed	Verify payment
Gateway	Flow is controlled or divided	Is payment valid?
Sequence flow	Shows order	Connects elements
Message flow	Shows communication between pools	Send invoice to customer

A common modeling mistake is using an event for work.

For example:

• “Review application” is an activity.

• “Application received” is an event.

• “Application approved?” is a gateway.

• “Send approval email” may be a send task or a message throw event, depending on the level of detail.

9. Events versus tasks

Use an event when the process is waiting for or reacting to something.

Use a task when someone or something performs work.

Situation	Better BPMN element
Wait for customer response	Message catch event
Ask customer for information	Send task
Check customer information	User or service task
Payment arrives	Message catch event
Process payment	Service task
Deadline passes	Timer event
Escalate a case	Escalation event or task, depending on meaning

For example:

Send approval request → Wait for approval message

The first step is work, so it is a send task. The second step is waiting, so it is a message catch event.

10. Event modeling patterns

Timeout pattern

Use a boundary timer when work must finish within a limit.

Review application
 └── Timer: 48 hours → Escalate

Approval-or-timeout pattern

Use an event-based gateway when either approval or a deadline determines the next path.

Request approval → Wait for approval or timeout

Exception-handling pattern

Use an interrupting error boundary event.

Call payment service
 └── Error → Log error → Notify support

Reminder pattern

Use a non-interrupting timer boundary event.

Wait for customer documents
 └── Timer: 3 days → Send reminder

The original waiting activity continues.

Cancellation pattern

Use a message boundary event or event subprocess when an external party can cancel the process.

Process order
 └── Cancellation message → Stop processing → Refund customer

Parallel approval pattern

Use parallel gateways when all approvals are required. Use a parallel multiple event when the process is specifically waiting for multiple event triggers.

Wait for manager approval
Wait for finance approval
Wait for legal approval
        ↓
Continue

11. Beginner modeling guidelines

1. Use a start event and an end event.
   They make the process boundaries clear.

2. Name events as things that happen.
   Good: “Payment received”
   Less suitable: “Receive payment” — this sounds like an activity.

3. Use tasks for work.
   “Review application” is a task, not an event.

4. Use message events for communication.
   They are especially useful when communicating across pools.

5. Use timer events for deadlines and waiting.
   Avoid hiding time limits in task names.

6. Use boundary events for exceptions related to a specific activity.

7. Decide whether an exception interrupts the work.
   Use interrupting or non-interrupting behavior intentionally.

8. Use event-based gateways only when the next path depends on an event.

9. Avoid too many event types in a simple diagram.
   A beginner-friendly process often needs only:

   • None start event

   • Message event

   • Timer event

   • Error boundary event

   • None end event

10. Make event names precise.
    Prefer:

    • “Approval received”

    • “Payment failed”

    • “Deadline reached”

    • “Cancellation requested”

12. A complete example

Consider an insurance claim process:

Message start: Claim submitted
        ↓
Validate claim
        ↓
Investigate claim
 ├── Error boundary → Notify claims support → End: Investigation failed
 ├── Timer boundary: 7 days → Escalate to supervisor
 └── Message boundary: Customer cancels
          ↓
       Close claim → End: Claim cancelled
        ↓
Approve claim
        ↓
Message throw: Send approval notification
        ↓
Timer: Wait 3 days
        ↓
Issue payment
        ↓
End: Claim completed

This example demonstrates:

• A message start event

• An error boundary event

• A timer boundary event

• A message boundary event

• A message throw event

• An intermediate timer event

• Multiple possible end states

13. Quick reference

Event	Main purpose
None	Generic start, intermediate point, or end
Message	Send or receive communication
Timer	Wait for or trigger a time condition
Error	Handle an error
Escalation	Raise a business issue
Cancel	Cancel a transaction
Compensation	Undo completed business work
Conditional	Wait for a condition
Signal	Broadcast information
Link	Connect distant diagram sections
Multiple	Respond to one of several event types
Parallel multiple	Wait for several event types

The simplest way to understand BPMN events is:

• Start events explain why a process begins.

• Intermediate events explain what the process waits for, sends, catches, or reacts to.

• Boundary events handle events that occur while an activity is running.

• End events explain how the process finishes.

• Event-based gateways let the first event to occur determine the path.