Message Flow

A message flow is a dashed arrow with an open arrowhead and a small envelope marker at its source or middle. It connects activities or events in *different pools*. Semantically it says "when this source step fires, a message is sent to the target step". Unlike sequence flows, a message flow does not transfer a token; each pool has its own tokens, and the message is the only thing that crosses the pool boundary.

That distinction matters because it pins down where control lives. A sequence flow implies "I run this, then I run that, same actor". A message flow implies "I send this; someone else, outside my control, decides whether and when to act on it". Every time a process touches a third party (a customer, a supplier, an external API) the boundary is a message flow, not a sequence flow.

• Message flows connect *different pools* only. Between activities in the same pool, use sequence flows.
• Sources are typically throwing message events, message end events, or activities that produce a message output. Targets are catching message events, message start events, or activities that consume a message input.
• A message flow to a collapsed (black-box) pool is fine. You do not have to model the other side.
• Do not mix sequence and message flows in a way that makes the pool-internal vs pool-external semantics ambiguous. A flow is one or the other.

LucidFlow places message flows wherever the source document describes asynchronous communication between parties: "we email the customer a link", "the bank sends us the settlement notice". The bottleneck heatmap computes message-flow waiting time as the gap between send and receive, which is usually the single largest duration on any inter-organisation process. Modelled this way, "the customer takes 4 days on average to respond" becomes a visible bottleneck you can target with a reminder automation.