skip to content

In BPMN 2.0, how do sequence flow, message flow and association differ in notation and in meaning?

level: juniorimportance: must knowfreq 50%

answer

  1. three line styles, three jobs
  2. what actually travels along each line
  3. open circle marks the sender
  4. dotted lines impose no order

basics

~20 s

In BPMN 2.0 a sequence flow (solid line, solid arrowhead) orders flow nodes inside one process and carries the token; a message flow (dashed, open circle to open arrowhead) passes a message between pools; an association (dotted) only attaches information.

solid answer

~50 s

BPMN 2.0.2 has three connector families and each has a fixed line style that tools may not restyle. A **sequence flow** is a solid single line with a solid arrowhead; it has exactly one source and one target flow node (event, activity or gateway) and it is the path the token follows inside **one** process. A **message flow** is a dashed line starting in an open circle and ending in an open arrowhead; it must connect two separate pools and shows a message passing between participants, so no token crosses it. An **association** is a dotted line, optionally with an arrowhead, that links artifacts such as a text annotation to a diagram element; a **data association** uses the directed-association look to move data into or out of an activity or event. Of the three, only sequence flow decides order.

go deeper

for a junior

Recall the three styles and the job of each: solid orders work inside a process, dashed carries a message between pools, dotted attaches information.

for a middle

Explain what moves on each connector: the token on sequence flow, a message on message flow, data on a data association, nothing on a plain association.

for a senior

Show you read a supplied diagram by connector style first, flagging any solid line crossing pools or dotted line mistaken for ordering.

for a principal

Discuss why the standard forbids restyling connectors and how diagram conventions keep collaboration models readable across teams and tools.

## Three connectors, three jobs BPMN 2.0.2 (OMG formal/13-12-09) defines three families of **connecting objects**. A reader who treats every arrow as "something happens next" misreads most collaboration diagrams, because only one of the three says anything about order. | Connector | How it is drawn (BPMN 2.0.2) | What it connects | What travels | |---|---|---|---| | **Sequence flow** | solid single line, solid arrowhead | flow nodes (events, activities, gateways) inside one process | the token | | **Message flow** | dashed single line, open circle at the start, open arrowhead at the end | two separate pools, or objects inside two separate pools | a message | | **Association** | dotted single line, arrowhead optional | artifacts and data to flow objects or flows | nothing | | **Data association** | drawn like a directed association | data objects, properties, data inputs and outputs of an activity or event | data (no token) | The specification (clause 7.5) says the line styles of sequence flows, message flows and associations **MUST NOT be modified or duplicated** by tool extensions. The style is therefore part of the meaning, not decoration. ## Sequence flow: the path of the token Clause 8.4.13 describes a **sequence flow** as showing the order of flow elements in a process. Key points: - Each sequence flow has **only one source and only one target**. - Source and target must be events, activities or gateways (the `FlowNode` subclasses); a data object, a pool, a lane, a group or a text annotation can never be either end. - It may cross the lanes of one pool but **never a pool boundary**, and it cannot leave an expanded sub-process for an object outside it. - It may carry an optional `conditionExpression`; a flow with a condition leaving an activity is drawn with a mini-diamond at its start, and a **default** flow is drawn with a slash marker. The **token** is the specification's teaching device: a start event creates one, it moves along sequence flows, and an end event consumes it. The standard is explicit that tools are NOT REQUIRED to implement any form of token, but every execution rule is phrased in terms of it. ## Message flow: communication between participants Clause 9.4 defines a **message flow** as showing the flow of messages between two participants that are prepared to send and receive them. In a purchase-order collaboration, the buyer's pool sends an order and the supplier's pool receives it; the connector between them is a message flow. - A message flow **MUST connect two separate pools**; it may end on the pool boundary or on a flow object inside the pool. - It **MUST NOT** connect two objects in the same pool. - The specification notes that a **token does not traverse a message flow**: a message is what is passed. The receiving process moves only when one of its own elements (a message start event, a receive task, a message catch event) consumes that message. ## Association and data association An **association** (clause 8.4.1, Artifacts) links information and artifacts to flow objects: a text annotation beside a task, or the compensation activity attached to a compensation boundary event. Its `associationDirection` attribute is `None` by default, or `One` or `Both`, which only controls the arrowheads. A **data association** is a different element with the same look as a directed association. It moves data between a data object or property and the inputs or outputs of an activity or event. The specification states that tokens do not flow along a data association, so it has no direct effect on the order of the process. ## Reading a diagram strictly When you are handed a buyer-supplier diagram, read each connector by its style before its label: 1. **Solid with a filled arrowhead** inside one pool: a sequence flow. Ask what it orders and whether it has a condition marker. 2. **Dashed with an open circle**: a message flow. Confirm it crosses a pool boundary and lands on something that can send or receive. 3. **Dotted**: an association or data association. It never makes the next task start. 4. Any solid line crossing between the buyer and supplier pools is a defect, whatever the label says. The practical consequence is that the order of work inside the supplier cannot be read from the buyer's arrows. Each pool's sequence flows describe its own process; the message flows describe only the conversation between them.

  • Can a BPMN 2.0 sequence flow cross from one lane to another?
    Yes. The glossary states a sequence flow can cross the boundaries between lanes of a pool but cannot cross the boundaries of a pool. Lanes partition one process, so moving between them is still ordering work inside that process. Crossing to another pool requires a message flow.
  • Does a BPMN 2.0 association carry a condition the way a sequence flow can?
    No. An association has a `sourceRef`, a `targetRef` and an `associationDirection` of `None`, `One` or `Both`; there is no `conditionExpression`. Conditions belong on sequence flows, where a token can be withheld if the condition is false.
  • Must a BPMN 2.0 tool implement tokens to be compliant?
    No. The specification calls the token a theoretical concept used to define behaviour and says modelling and execution tools are NOT REQUIRED to implement any form of token. The token is the reading aid that makes flow semantics precise.

Sequence flow is the internal routing slip passed desk to desk inside one company; message flow is the letter posted to another company; an association is a sticky note clipped to a page. Only the routing slip decides who works next.

saying these in an interview costs you the question

  • Believing a token travels along a message flow into the other pool
  • Treating a dotted association arrow as the next step in the process
  • Thinking connector line styles are cosmetic and may be restyled freely
  • Drawing a message flow between two lanes of the same pool
  • Assuming a sequence flow may have several targets like a fan-out arrow