Module 4 · BPMN Exceptions and Timers

Message Events

Lesson 2 of 3

What a Message Event models

A Message Event represents a communication crossing a Pool boundary. It is used when the process pauses to wait for input from another participant, when it sends something to one, or when a communication triggers the process to begin.

The key word is crossing a Pool boundary. Messages in BPMN are cross-organisational or cross-system communications. Internal communications between departments are modelled using Sequence Flow and Lane crossings, not Message Events.

Message Event types

TypePlacementWhat it modelsExample
Message Start EventStart of PoolProcess triggered by receiving a message from an external participantInvoice approval starts when supplier sends invoice
Message Intermediate Catch EventWithin the flowProcess pauses and waits for a message before continuingAfter sending a discrepancy query, wait for supplier's response
Message Intermediate Throw EventWithin the flowProcess sends a message and continues without waitingSend confirmation email to customer and move to next step immediately
Message End EventEnd of PoolProcess ends by sending a messageProcess ends when rejection notice is sent to supplier
Message Boundary EventOn edge of TaskA message can arrive while the task is activeCustomer cancels order while warehouse is picking goods

Common mistake

Using Message Events for internal communications between Lanes in the same Pool. An email from a Finance Clerk to a Finance Manager is internal — it should be modelled as a Sequence Flow crossing a Lane boundary, not as a Message Event. Message Events are for cross-Pool, cross-organisation, or cross-system communication only.

Message Flow vs. Message Event

These are related but different. Message Flow (the dashed arrow between Pools) shows that a communication exists between participants. Message Events add detail about when and how that communication triggers or responds within the process flow.

You can have Message Flow without Message Events (for simplified diagrams that show communication without detailing the trigger mechanics). But if you use a Message Start or Catch Event, there should be a corresponding Message Flow showing where the message comes from.

✓ When to use

  • Message Start Event when your process is triggered by a communication from an external party
  • Message Catch Event when your process must pause and wait for a response before continuing
  • Message End Event when the act of sending a message is the final step in the flow
  • Message Boundary Event when an external message can arrive during a task and needs to be handled

✗ When not to use

  • Don't use Message Events for internal department communications — those are Sequence Flows
  • Don't add a Message Throw Event for every email or notification — only when the sending itself is a meaningful step