In BPMN 2.0, how do start, intermediate and end events differ, and what makes an event catching rather than throwing?
answer
- three circle borders
- where tokens are born and consumed
- start reacts, end produces
- marker fill tells direction
basics
~20 sIn BPMN 2.0 a start event (thin circle) only catches the trigger that creates a process instance, an end event (thick circle) only throws a result as it consumes a token, and an intermediate event (double circle) may catch or throw.
solid answer
~40 sBPMN 2.0 classifies events by position. A **start event** is a single thin circle: it can only *catch* a trigger, such as a message, a timer or a signal, and each occurrence starts a new process instance. An **end event** is a single thick circle: it can only *throw* a result (none, message, error, signal, terminate and so on) and it consumes the token that reaches it. An **intermediate event** is a double circle between the two; in normal flow a *catching* one holds the token until its trigger occurs ("payment received"), while a *throwing* one fires its trigger at once and lets the token move on ("send order confirmation"). The marker gives the direction: **unfilled** means catching, **filled** means throwing. An intermediate event attached to an activity boundary can only catch.
go deeper
Recall the three borders (thin, double, thick) and that start only catches, end only throws, and intermediate does either. Read the marker fill before naming what an event does.
Explain what the token does at each position: created at a start, held or passed at an intermediate, consumed at an end. Know that the instance completes only when no token remains.
When reviewing a model, check every intermediate envelope's fill and every path's end: a catching event drawn as throwing silently removes a wait, and a path with no end changes when the instance completes.
Set modelling conventions a team can review against: explicit start and end events per level, one event per business fact, and naming that states whether the event waits or announces.
## What an event is in BPMN 2.0 In BPMN 2.0 (OMG formal/13-12-09) an **event** is something that *happens* during a process, as opposed to an **activity**, which is work that is *performed*. Every event is drawn as a circle, and the specification separates events along two independent dimensions: - **Position** in the flow: start, intermediate or end, shown by the circle's border. - **Type**, the trigger or result: none, message, timer, error, escalation, cancel, compensation, conditional, link, signal, terminate, multiple and parallel multiple, shown by the marker inside the circle. This question is about the first dimension, and about the direction an event works in: catching or throwing. ## The three positions | Position | Border | Direction | Effect on the token | |---|---|---|---| | Start event | single thin line | catch only | creates a token (a new process instance at the top level) | | Intermediate event | double thin line | catch or throw in normal flow; catch only on a boundary | holds or passes the token | | End event | single thick line | throw only | consumes the token | The specification's overview puts it in one line: start events can only react to ("catch") a trigger, end events can only create ("throw") a result, and intermediate events can catch or throw triggers. The sequence-flow rules follow from the same idea: - A **start event** must not have incoming sequence flow and must have outgoing sequence flow. If several sequence flows leave it, each gets its own token and a parallel path starts. - An **end event** must have incoming sequence flow and must not have outgoing sequence flow. It is the sink for every token that arrives. - An **intermediate event in normal flow** must have both an incoming and an outgoing sequence flow (the two ends of a link pair are the exceptions: the throwing link has no outgoing flow and the catching link no incoming one). ## Catching versus throwing A **catching event** waits for something outside the current path: a message from another participant, a point in time, a condition becoming true, a broadcast signal. A **throwing event** produces something: it sends a message, broadcasts a signal, raises an escalation or an error, or triggers compensation. The notation makes the direction visible: - the marker of a **catching** event is **unfilled** (an outline envelope, an outline triangle); - the marker of a **throwing** event is **filled** (a solid envelope, a solid triangle). What happens when a token reaches an intermediate event in normal flow: 1. If it is a **throwing** event, the trigger occurs immediately (for example the message is sent) and the token moves straight on down the outgoing sequence flow. 2. If it is a **catching** event, the token stays at the event until the trigger occurs (for example the message is received); then it moves on. Some types have only one direction. A timer and a conditional event are always catching; a none intermediate event, an escalation and a compensation event in normal flow are always throwing; message, signal, link and multiple can be either. ## An order-fulfilment walk-through Take a simple order-fulfilment process: 1. A **message start event**, "Order received", catches the customer's order and creates the process instance. 2. The task "Check stock" runs. 3. A **throwing message intermediate event**, "Send payment request", sends the request and the token moves on at once. 4. A **catching message intermediate event**, "Payment received", holds the token until the payment message arrives. 5. The task "Ship order" runs. 6. A **message end event**, "Send dispatch notice", sends the notice and consumes the token; with no token left, the instance completes. The two envelopes in steps 3 and 4 look the same apart from the fill, which is exactly why the fill rule matters when reading a diagram. ## Rules that are easy to get wrong - **Start and end events are optional**, per process level. But if a level has a start event, it must have at least one end event. - Without a start event, every flow node that has no incoming sequence flow starts its own parallel path; without an end event, a path ends at any node with no outgoing flow. - A process instance is **complete only when all its tokens are consumed**. Reaching one ordinary end event ends one path, not the whole instance (only a terminate end event ends everything). - An intermediate event **attached to an activity boundary can only catch**; it never throws. - A **sub-process start event** has no trigger at all ("none"): the token arriving from the parent flow is what starts it. - The events in a **multiple** event are alternatives when catching (any one triggers it) and all happen when throwing (every result is produced); a **parallel multiple** event catches only when every trigger has occurred.
- In BPMN 2.0, must every process level have a start event and an end event?No, both are optional. But if a level has a start event it must have at least one end event. Without a start event, each flow node with no incoming sequence flow starts its own parallel path; without an end event, a path ends at any node with no outgoing flow, and the instance completes once all tokens are consumed.
- In BPMN 2.0, what happens when two sequence flows leave a single start event?Each outgoing sequence flow receives its own token, so two parallel paths begin at once. The flows leaving a start event must not carry conditions; if a choice is needed, it belongs in a gateway after the start event.
A relay race: the starter's pistol (start event) is something the runner reacts to, the finish line (end event) is where the baton is handed in, and the handovers in between (intermediate events) either wait for the next runner or pass the baton on.
saying these in an interview costs you the question
- A start event can throw a message to announce the process began.
- An end event can wait for a reply before completing.
- Filled versus unfilled markers mean mandatory versus optional triggers.
- A boundary event can throw a trigger as well as catch one.
- Reaching any end event stops every other path in the process.