Pools and messages

A process often talks to someone outside it, such as a customer, a carrier or a bank. Declare each one with a pool line near the top. It's drawn as a band across the diagram, above your process, or below it with (below). These pools show that the party exists and what passes between you, not the party's own steps.

Then put messages under the steps that send or receive them. => sends a message to a pool and <= receives one, followed by the pool's name, a colon and what's sent:

process Order tracking
pool Customer
pool Carrier (below)

start:message Order placed
  <= Customer: Order
send Book pickup
  => Carrier: Pickup request
receive Pickup confirmed
  <= Carrier: Picked up
send Notify customer
  => Customer: Tracking update
end Order shipped

Each message is drawn as a dashed line between the step and the pool's band, labeled with what's sent. Message lines don't change how steps connect.

RulesCopy Anchor Link

• A message goes between a step of your process and a pool, never between two steps (that's a flow) or two pools.
• Tasks can send and receive. A start or catch event only receives and a throw or end event only sends; make it a message event, as in start:message. Timer, error and other typed events, gateways and boundary events can't have messages.
• In the BPMN XML, pools become participants in a collaboration and messages become message flows.

Pool names with special charactersCopy Anchor Link

A pool whose name has ->, : or # in it needs an id, and its messages name it by that id:

pool Sales -> EU #sales_eu

send Send order
  => #sales_eu: Order

Once a diagram has pools, the checks also suggest a message for every message event, for every send or receive step whose name mentions a pool, and for every pool that has none. See Modeling checks.