In BPMN 2.0, when should a sub-process throw an error rather than an escalation, and how does each reach its catching event?
answer
- critical versus non-critical
- what happens at the throw point
- nearest enclosing boundary
- matching code or none
- dashed is possible for one
basics
~20 sIn BPMN 2.0 an error is critical: its end event terminates the sub-process's active paths and an always-interrupting boundary event catches it. An escalation is non-critical: work continues where it was thrown, and the catching boundary event may be non-interrupting.
solid answer
~50 sBoth are **propagated** triggers: BPMN 2.0 forwards them from where they are thrown to the innermost enclosing scope that has a boundary event able to catch them, matching on `errorCode` or `escalationCode` (a catching event without a code catches any). The difference is criticality. An **error** is critical: among events only an error end event throws it, all active paths in that sub-process are terminated, and the boundary error event always interrupts. Use it when the work cannot continue, such as "Out of stock" in a "Reserve stock" sub-process. An **escalation** is non-critical: it can be thrown by an intermediate event or an end event, other paths keep running, and the boundary escalation event may be interrupting or not. Use it to tell a higher level something without aborting, such as "high-value order needs approval".
go deeper
Recall that an error is critical and always interrupts, while an escalation is a non-critical notice that can leave work running.
Explain propagation to the nearest enclosing boundary, code matching (same code or no code catches), and which events can throw each trigger.
Check every thrown error has an enclosing catcher, and that business notices are escalations, not errors, so models never kill work that should continue.
Agree an error and escalation catalogue with the business, with codes and owners, so handling stays consistent across process models and levels.
## Two propagated triggers BPMN 2.0 (OMG formal/13-12-09) forwards event triggers in several ways: publication (messages and signals), direct resolution, propagation, cancellation and compensation. **Error** and **escalation** are the two triggers that are **propagated**: the trigger travels from the place where it was thrown to the **innermost enclosing scope instance** that has an attached event able to catch it. In practice that means the boundary of the nearest enclosing sub-process or call activity with a matching catch event. Matching works on a code: - a boundary error event catches an error with the **same `errorCode`**, or, if it has **no `errorCode`**, any error; - a boundary escalation event catches an escalation with the **same `escalationCode`**, or, if it has none, any escalation. ## The difference: critical versus non-critical The specification states it directly: error triggers are **critical** and suspend execution at the location of throwing; escalations are **non-critical** and execution continues at the location of throwing. | | Error | Escalation | |---|---|---| | Nature | critical: the work cannot go on | non-critical: someone above should know or act | | Thrown by | an error end event (or implicitly by a failed operation) | an escalation intermediate event in normal flow, or an escalation end event | | Effect where thrown | all active paths in that sub-process are terminated | other active paths are not affected and continue | | Catching boundary event | always interrupting (solid border) | interrupting or non-interrupting (solid or dashed) | | Catching in normal flow | not allowed | not allowed (normal-flow escalation events only throw) | | If nothing catches it | behaviour unspecified by the standard | behaviour unspecified by the standard | ## Choosing between them in an order-fulfilment process Consider a sub-process "Reserve stock" inside an order-fulfilment process. 1. **Stock is unavailable.** The order cannot be fulfilled as placed. Model an **error end event** with `errorCode` "OUT_OF_STOCK" inside the sub-process. Any other active path in the sub-process is terminated, and the boundary error event on "Reserve stock" catches the error and routes the token to "Offer back-order or refund". The sub-process is over. 2. **A reservation takes longer than usual, or the order value exceeds an approval limit.** Nothing has failed; a supervisor should know. Model an **escalation intermediate throw event** "Notify supervisor" inside the sub-process, and a **non-interrupting** boundary escalation event on "Reserve stock" that starts "Review order" in parallel. The reservation keeps going. 3. **The supervisor must decide before reservation continues.** Keep the escalation, but make the boundary escalation event **interrupting**: the sub-process is cancelled and the process follows the exception flow. This is a modelling choice, not a property of escalations. The quick test: if the thrower **cannot continue**, it is an error; if the thrower **can continue** and the parent may or may not need to intervene, it is an escalation. ## What the standard does not decide - **Unresolved triggers.** If no activity in the hierarchy catches an error, the process's behaviour is **unspecified**; the specification notes an executing system may add its own handling, a common one being termination of the process instance. The same unspecified status applies to an uncaught escalation. A model should not rely on either. - **Error versus operation faults.** An error can also represent the fault of a failed service operation, so a service task's technical failure may surface as a BPMN error without an explicit error end event. - **Compensation is separate.** An error does not undo work that already completed; undoing it needs an explicit compensation throw. ## Mistakes that reveal a weak model - Using an error for a business *notice*, which kills in-flight work the business wanted to continue. - Trying to catch an error with an intermediate event in normal flow, which the specification forbids. - Drawing a dashed boundary error event to keep the activity running; only escalation offers that. - Assuming an uncaught error ends the process cleanly; the standard leaves it unspecified. - Putting the catching boundary event on an activity that does not enclose the thrower; propagation only goes outward through enclosing scopes.
- In BPMN 2.0, what happens if no enclosing activity catches a thrown error?The standard leaves it unspecified. It says the executing system may define additional handling, a common choice being to terminate the process instance, but a portable model should always place a matching boundary error event, or one without an errorCode, on an enclosing activity.
- In BPMN 2.0, why use an escalation rather than a message to tell the parent level something?Messages go between participants and are published to a specific receiver. An escalation stays inside the process hierarchy and is propagated automatically to the nearest enclosing activity that can catch it, so the sub-process does not need to know who handles it.
saying these in an interview costs you the question
- An escalation always cancels the activity that raised it.
- An error can be caught by an intermediate event in normal flow.
- The standard says an uncaught error simply completes the process.
- A boundary error event can be made non-interrupting to allow retries.
- Error and escalation differ only in their marker shape.