In BPMN 2.0, which event triggers may a top-level start event, an end event and a boundary event each use?
answer
- seven ways to start
- nine end results
- ten boundary triggers
- link and none never attach
- terminate only ends
basics
~20 sIn BPMN 2.0 a top-level start event catches none, message, timer, conditional, signal, multiple or parallel multiple; an end event throws none, message, error, escalation, cancel, compensation, signal, terminate or multiple; a boundary event catches anything except none and link.
solid answer
~40 sBPMN 2.0 fixes which triggers each position accepts. A **top-level start event** has seven options: none, message, timer, conditional, signal, multiple and parallel multiple; a sub-process start event is always none, because the parent's token starts it. An **end event** has nine results: none, message, error, escalation, cancel, compensation, signal, terminate and multiple. A **boundary event** accepts message, timer, error, escalation, cancel (transaction sub-process only), compensation, conditional, signal, multiple and parallel multiple; **none** and **link** never attach. So no intermediate event in normal flow throws or catches an error (an error end event throws it and a boundary event catches it), **terminate** exists only as an end event, a **timer** can never be thrown, and a **link** pair is a same-level go-to used only in normal flow.
go deeper
Recall that timers and conditions can only be caught, that terminate is only an end event, and that none and link events never sit on a boundary.
Explain the rule behind the table: start catches external triggers, end throws consequences, boundaries catch what happens to a running activity. Know the link pair's single-level limit.
Spot a trigger in an impossible position during review, such as an error in normal flow or a link crossing into a sub-process, and replace it with the construct that has the intended semantics.
Choose a restricted, reviewable trigger palette for your organisation's models, and document which rarely used ones (parallel multiple, conditional start) are allowed and why.
## Why the positions restrict the triggers In BPMN 2.0 (OMG formal/13-12-09) an event's **trigger** (for catching events) or **result** (for throwing events) is its type: message, timer, error and so on. The position of the event decides which types make sense. A start event can only catch, so nothing that is purely a *result* can start a process. An end event can only throw, so a timer or a condition, which can only be waited for, cannot end one. A boundary event can only catch something that happens *to* the running activity. ## The trigger table | Trigger | Top-level start | Intermediate, normal flow | Boundary | End | |---|---|---|---|---| | None | yes | throw | no | yes | | Message | yes | catch or throw | yes | yes | | Timer | yes | catch | yes | no | | Conditional | yes | catch | yes | no | | Signal | yes | catch or throw | yes | yes | | Escalation | no | throw | yes | yes | | Error | no | no | yes (always interrupting) | yes | | Cancel | no | no | yes (transaction sub-process only) | yes | | Compensation | no | throw | yes | yes | | Link | no | catch or throw | no | no | | Terminate | no | no | no | yes | | Multiple | yes | catch or throw | yes | yes | | Parallel multiple | yes | catch | yes | no | The counts the specification states are useful anchors: **seven** start event types for a top-level process, **nine** end event types, **twelve** intermediate event types of which **ten** may be used in normal flow (error and cancel may not). A sub-process uses only a **none** start event, because the token arriving from the parent flow is its trigger. ## The triggers that surprise people - **Error.** A catching error *intermediate* event may only sit on an activity boundary; it may not be used in normal flow. Among the events of a process's flow, only an **error end event** throws an error (a failed service operation can also surface as one). It is caught by a boundary error event with the same `errorCode`, or with no `errorCode`, on the nearest enclosing activity. - **Terminate.** Only an end event. It ends every active activity in the process at once, including all instances of multi-instance activities, without compensation or event handling. Used inside a sub-process, it terminates only that sub-process instance; the parent carries on. - **Link.** Only in normal flow and only within a **single process level**: it cannot connect a parent process with a sub-process. A throwing (source) link has an incoming flow and no outgoing flow; a catching (target) link with the same name has an outgoing flow and no incoming one. Several source links may point at one target link. Links are off-page connectors or generic go-to objects, often used to draw a loop without a long line. - **Timer and conditional.** Only ever caught. A timer is set as a date, a duration or a cycle, and each expression must return an ISO 8601 representation; a conditional event fires when its condition becomes true, and for a conditional start event the specification adds that the condition must become false and then true again before it can fire again. - **Signal versus message.** A signal is **broadcast**: any process that can catch it may react, across process levels and pools. A message is **directed** at a specific participant and, when it must reach one process instance, uses correlation. - **Cancel.** Only in a **transaction sub-process**: a cancel end event inside it triggers the cancel boundary event on its edge. ## Events waiting after an event-based gateway The gateway itself is a separate subject, but the events that follow it are event types. Only **message, signal, timer, conditional** and **multiple** (made of those) intermediate catch events are valid targets; **error, cancel, compensation** and **link** are not. For an order-fulfilment process the configuration is typically a "Payment received" message, a "Cancellation received" message and a 48-hour timer, and whichever occurs first decides the path. ## How to reason about a trigger you are unsure of 1. Ask whether the trigger comes **from outside** the current path (message, timer, signal, condition). If so, it can be caught at a start or intermediate position. 2. Ask whether it is a **consequence** the process produces (error, escalation, compensation, terminate). If so, it is thrown, and a start event cannot use it. 3. Ask whether it concerns an **activity already running**. If so, it belongs on a boundary. 4. Check the special restrictions: none and link never attach to a boundary, terminate exists only as an end event, cancel needs a transaction.
- In BPMN 2.0, what does a terminate end event do that a none end event does not?A none end event consumes only the token that reaches it; the instance completes once no token remains. A terminate end event ends every active activity in that process at once, including all multi-instance instances, without compensation or event handling. Inside a sub-process it terminates only that sub-process instance, and the parent continues.
- In BPMN 2.0, why is a sub-process start event always a none event?Because the token arriving from the parent flow is what instantiates the sub-process, so no further trigger is needed. Table 10.85 lists none as the only start event type for a sub-process; a reusable process called by a call activity is also started through its none start event.
saying these in an interview costs you the question
- A top-level process can be started by an error raised elsewhere.
- A link event pair can jump from a parent process into its sub-process.
- A terminate end event ends only the path that reached it.
- A timer event can be thrown to wake another process.
- An intermediate event in normal flow can throw an error.