Message Flow
The dashed connector that carries a message between two different participants (Pools). Open circle at the origin, open arrowhead at the target.
The Message Flow is the only legal channel between Pools: order, invoice, confirmation — every inter-participant exchange rides on one. It may attach to the Pool border (black box) or to a specific message-aware element inside (message events, send/receive tasks).
Labeling each message flow with its payload (“Purchase order”) turns the collaboration into a readable interface contract.
When to use and avoid
When to use
For every communication between different participants.
To document the message choreography of a collaboration: who sends what, when.
Attached to message events / send / receive tasks to show exact touchpoints.
When NOT to use
Inside a single Pool — internal hand-offs are sequence flows.
To represent shared database access — that is a Data Store association.
Between lanes of the same Pool — lanes are the same participant.
Business example
PO and confirmation between customer and supplier
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The message flow “Purchase order” (highlighted) crosses from the Customer Pool to the supplier's message start event.
- The supplier confirms availability internally (sequence flows).
- The message flow “Order confirmation” (highlighted) carries the reply back — the pair documents the full conversation contract.
Differences
Message Flow vs Sequence Flow
Communication vs ordering: message flows move information between participants; sequence flows move the token within one. Style gives it away instantly — dashed vs solid.
FAQ
Where exactly can a message flow connect?
Pool borders, message start/intermediate/end events, and send/receive tasks. Never gateways, and never elements of the same Pool.
Should message flows be labeled?
Strongly recommended — the label (the message name) is what turns the diagram into an interface specification.