skip to content

In BPMN 2.0, which sequence-flow and message-flow connections are illegal at start events, end events, boundary events and gateways?

level: middleimportance: should knowfreq 35%

answer

  1. where a token is born and dies
  2. boundary events only emit
  3. gateways never talk to partners
  4. senders and receivers are asymmetric

basics

~20 s

In BPMN 2.0 no sequence flow may enter a start event or a boundary event, or leave an end event; gateways take no message flows; start events never send and end events never receive message flows.

solid answer

~50 s

BPMN 2.0.2 fixes each endpoint's role. A **start event** MUST NOT have incoming sequence flows and MUST have an outgoing one; it may receive message flows (each is a trigger) but never send them. An **end event** MUST have an incoming sequence flow and MUST NOT have an outgoing one; it may send message flows (its result is then `Message` or `Multiple`) but never receive them. An intermediate event **attached to an activity boundary** MUST NOT have an incoming sequence flow and MUST have an outgoing one, except a compensation boundary event, which uses an association instead. **Gateways** take sequence flows only, never message flows. A **message intermediate event** has one incoming or one outgoing message flow, not both. Data objects and other artifacts take neither connector. The two standard exceptions are start and end events drawn on the boundary of an expanded sub-process.

go deeper

for a junior

Recall the plain rules: nothing flows into a start event or out of an end event, and gateways never exchange messages.

for a middle

Explain each rule from the token model and apply the per-element message-flow rules when reviewing a collaboration diagram.

for a senior

Know the exceptions, such as start and end events on an expanded sub-process boundary and compensation associations, so you do not flag legal models.

for a principal

Argue for automated validation of these rules in a shared modelling practice, since a diagram that breaks them cannot be read unambiguously.

## Why endpoints have fixed roles BPMN's connection rules follow from the token model. A **start event** is where a token is created, an **end event** is where it is consumed, a **gateway** routes tokens inside one process, and a **message** is something only a participant's sending or receiving element can handle. The specification states the rules per element in chapter 10 and summarises them in Tables 7.3 (sequence flow) and 7.4 (message flow). ## The rules in one table | Element | Incoming sequence flow | Outgoing sequence flow | Incoming message flow | Outgoing message flow | |---|---|---|---|---| | **Start event** | MUST NOT (exception below) | MUST have one | may (each is a trigger) | MUST NOT | | **End event** | MUST have one | MUST NOT (exception below) | MUST NOT | may (result `Message` or `Multiple`) | | **Intermediate event in normal flow** | MUST have one | MUST have one (a source link event is exempt) | message event: at most one | message event: at most one, not with an incoming one | | **Boundary intermediate event** | MUST NOT | MUST have one (compensation: none, association instead) | message event: at most one | no: a boundary event only catches | | **Gateway** | yes | yes | never | never | | **Activity** | may, several | may, several | may, several | may, several | | **Data object, group, text annotation** | never | never | never | never | ## The exceptions a strict reader must know 1. **Expanded sub-process boundary.** A start event attached to the boundary of an expanded sub-process may receive a sequence flow from the higher-level process in place of connecting to the sub-process boundary; an end event on that boundary may likewise be the source of a sequence flow into the parent. 2. **Compensation boundary event.** It MUST NOT have an outgoing sequence flow; it may have an outgoing **association** pointing at the compensation activity. 3. **Link intermediate events.** A link event is a source link or a target link, never both, and a source link is not required to have an outgoing sequence flow; the pairing works like an off-page connector. ## Worked review: a purchase-order collaboration Suppose the buyer's and supplier's diagrams contain the following. Each is illegal for a different reason. - A sequence flow from `Resend order` back into the buyer's **start event** to retry. Start events accept no incoming sequence flow; a loop must go back to an activity or a gateway. - A message flow from the supplier's `Send confirmation` task into the buyer's **end event**. End events cannot receive messages; the buyer needs a receive task or a message catch event on its path. - A message flow from the supplier into an **exclusive gateway** that should route the order. Gateways do not take message flows; the message must be caught first, then routed. - A sequence flow drawn **into** a timer boundary event on `Wait for delivery`. Boundary events are triggered while the activity runs; they never receive sequence flow. - A single message intermediate event with an incoming **and** an outgoing message flow, meant to receive the order and acknowledge it. The specification allows one or the other, not both; split it into a catch and a throw. ## Why the rules matter beyond neatness - An illegal sequence flow into a start event produces a model whose token origin is undefined; any check applying the specification's rules flags it. - A message flow into an end event implies the end event waits for something, but an end event only produces results. - A gateway with a message flow hides the receipt of the message; the diagram then cannot say which element consumes it or what happens if it never arrives. A practical review habit is to walk each event and gateway in turn and ask two questions: which connector types touch it, and in which direction. Most illegal models fail on one of those two, and fixing them usually means inserting the missing catching or throwing element rather than rerouting a line. The general sentence to remember: sequence flows connect flow nodes inside one process under per-element rules, and message flows connect elements that can **send** to elements that can **receive**, across pools.

  • In BPMN 2.0, what does a start event with several outgoing sequence flows mean?
    Each outgoing sequence flow starts a separate parallel path with its own token. The specification also requires the conditionExpression of every sequence flow leaving a start event to be None, so you cannot use conditions there.
  • In BPMN 2.0, what happens if an activity has no incoming sequence flow?
    It is instantiated when the process is instantiated, so it runs at process start alongside the start event's path. Compensation activities and event sub-processes are the exceptions; a stray task without incoming flow is therefore a hidden parallel start.
  • In BPMN 2.0, may an end event send a message to a partner pool?
    Yes. An end event may be the source of zero or more message flows, one message sent per flow when it is triggered, and its result attribute must then be Message or Multiple.
  • In BPMN 2.0, can a single message intermediate event both receive the order and send an acknowledgement?
    No. A message intermediate event may have an incoming message flow or an outgoing one, but not both. Model a catching message event followed by a throwing one, or a receive task followed by a send task.

saying these in an interview costs you the question

  • Looping a retry sequence flow back into the start event
  • Pointing a partner's message flow at the receiving process's end event
  • Sending a message flow into a gateway to route the incoming order
  • Drawing a sequence flow into a boundary event to trigger it
  • Believing a compensation boundary event continues with a sequence flow