BPMN Escalation vs Error Events: Key Differences, Examples, and Best Practices

Many BPMN practitioners understand that both Error Events and Escalation Events represent exceptional situations. However, choosing the wrong event type can significantly change the meaning of a Process.

This article explains the differences between Escalation and Error Events, when to use each one, and how to avoid common modeling mistakes.

Key Takeaways

• Use an Error Event when an Activity fails and cannot complete normally.
• Use an Escalation Event when attention or intervention is required, but the Activity itself may still complete successfully.
• Errors represent failures; Escalations represent business situations that require action.
• Error Boundary Events are always interrupting.
• Escalation Events can be either interrupting or non-interrupting.
• Escalation Events are often a better choice when a manager, supervisor, or another stakeholder must be informed without terminating the Process.

Understanding Error Events

According to the BPMN specification, Error Events are used to model faults or failures that occur during Process execution. An Error Event indicates that something has gone wrong and that normal processing cannot continue as expected.

Error Events are typically associated with:

• System failures
• Technical exceptions
• Invalid operations
• Missing resources
• Service invocation failures

Error Example: Credit Card Payment Failure

Imagine an online store processing a customer payment. The Process performs the following steps:

1. Validate order
2. Charge credit card
3. Ship product

Suppose the payment gateway returns: "Payment declined". The payment Activity cannot complete successfully. Collecting payment cannot be achieved, therefore normal processing cannot continue.

The Payment Sub-Process has failed and must be handled through an exception flow such as:

• Notify the customer
• Request another payment method

The Activity itself cannot achieve its objective.

Understanding Escalation Events

Escalation Events serve a different purpose. An Escalation does not necessarily indicate a failure. Instead, it signals that a situation requires attention from another role, department, or level of authority. The Process may still be progressing successfully, but additional involvement is required.

Common Escalation scenarios include:

• Approval limits exceeded
• VIP customer handling
• SLA violations
• High-priority incidents
• Risk management procedures

Escalation Example: VIP Customer Complaint

A telecom company handles customer complaints. Most complaints are handled by Customer Service Representatives. However, if the customer is classified as a VIP:

• Management should be informed immediately.
• Additional monitoring should begin.
• The customer should receive priority treatment.

Importantly:

• The Complaint Handling Process itself should continue.
• We don't want to stop the work already being performed by the support agent.

The complaint itself is still being investigated and resolved by the support representative. The Escalation simply ensures that management is aware of a VIP customer situation.

Error and Escalation Example: Order Fulfillment and Procurement

To see how Error and Escalation Events are used in a more comprehensive process, let's look at a well-known example from the BPMN specification community (“BPMN 2.0 by Example”). 

Imagine this scenario: A company receives a customer order and checks stock availability.

• If the item is available, it is shipped immediately and payment is processed.
• If it is not available, the company orders it from a supplier before shipping (Procurement).

While waiting for the supplier, three things can happen:

1. Everything goes normally - the item arrives on time and the order proceeds as planned.
2. Delivery is delayed (shown in green) - the supplier warns about late delivery, so the company reacts (e.g. informs the customer), but the Process continues.
3. Item becomes undeliverable (shown in red)- the supplier cannot fulfill the order at all (e.g., out of stock or production failure). The company must stop procurement and handle a failure case (e.g. remove article from catalogue).

Inside Procurement:

• Normal flow continues until item is delivered.
• A non-interrupting Escalation may trigger a side reaction while Procurement continues.
• An interrupting Error Event would stop Procurement and force an exception handling path.

An Escalation is:

• A warning or situation that needs attention
• Part of normal business handling (“we need to react”)
• Does NOT necessarily stop the Process
• Can be handled while continuing the work

An Error is:

• A serious failure that breaks the Activity
• The current Process cannot continue as planned
• The Activity is immediately stopped
• Must be handled by an exception path (often outside or higher level)

Key difference in one sentence

• Escalation means "someone needs to know"
• Error means "something has failed"

The Fundamental Difference

The easiest way to distinguish between Error and Escalation is to ask:

Did something fail?

If the answer is yes, use an Error Event.

Examples:

• Payment rejected
• Service unavailable
• Database connection lost
• Validation failed

Does someone need to be informed or involved?

If the answer is yes, use an Escalation Event.

Examples:

• Approval threshold exceeded
• Customer complaint requires management review
• Delivery delay exceeds SLA
• High-risk transaction detected

Error Events always represent failure

A common modeling mistake is using Error Events whenever an unusual situation occurs. Not every exception is an Error. Consider the following statement: "The customer requested an amount that requires manager approval". Many modelers incorrectly represent this as an Error Event.

However:

• Nothing failed.
• The data is valid.
• The Process is functioning correctly.

The only difference is that another participant must become involved. This is an Escalation, not an Error.

Escalation Events can be Interrupting or Non-Interrupting

One of the most powerful features of Escalation Events is their flexibility.

Interrupting Escalation

The current Activity or Sub-Process is stopped. The Process immediately follows the Escalation handling path.

Example:

• A suspicious banking transaction requires immediate investigation.
• The current processing must stop until the investigation is completed.

Non-Interrupting Escalation

The Process continues while another path is triggered.

Example:

• A customer support ticket approaches its SLA deadline.
• The support specialist continues working on the ticket.
• At the same time, a supervisor receives a notification.
• The work continues while management is informed.
• This behavior cannot be modeled using Error Events.

Comparison Table

Final Thoughts

When choosing between Escalation and Error Events, focus on the business meaning rather than the notation.

Ask a simple question: Did the Activity fail, or does someone simply need to become involved? If the Activity failed, use an Error Event. If the Process requires attention, authority, or intervention without representing a failure, use an Escalation Event.

Making this distinction correctly leads to BPMN diagrams that communicate intent more clearly, align better with business reality, and are easier for stakeholders to understand.