Modeling Message Flows and Shared Responsibilities

When you’re modeling a process that spans multiple departments or organizations, the temptation is to connect everything with sequence flows. But that’s where things go wrong—fast.

Message flows are the correct answer. They’re not just a visual nicety; they’re the foundation of accurate, stakeholder-aligned collaboration diagrams.

I’ve seen teams waste weeks trying to force internal sequence flows across pools. It creates confusion, hides ownership, and breaks the model’s integrity. The moment you use a message flow instead, clarity emerges.

This chapter walks you through the practical mechanics of modeling BPMN message flows, how they differ from sequence flows, and how to assign responsibilities clearly using pools and lanes. You’ll learn how to avoid the most common modeling anti-patterns and build diagrams that stakeholders actually trust.

By the end, you’ll know how to model B2B interactions, departmental handoffs, and shared workflows with precision—without overcomplicating the diagram.

Understanding Message Flows vs. Sequence Flows

It starts with a fundamental distinction: sequence flows are internal. Message flows are external.

A sequence flow shows the order of activities within a single process. It’s the thread that runs through one pool, from start to end.

A message flow, by contrast, represents communication between participants. It crosses pool boundaries and signals that one participant is sending a message to another.

You can’t use a sequence flow to connect two separate pools. If you do, you’re implying that one participant is orchestrating the other—a false assumption in most real-world cases.

Think of message flows as the postal system of your model. They carry information, not control. They don’t dictate what happens next inside the receiving pool—they simply notify it that something has occurred.

When to Use Each Flow Type

Use sequence flows when modeling:

• Internal steps within a single process
• Decision paths inside a participant’s workflow
• Internal looping or error handling

Use message flows when modeling:

• Handoffs between departments
• Customer notifications from a system
• Order confirmations from a supplier
• Approval requests between teams

Never mix them. A message flow should never connect two activities in the same pool. That’s a red flag. It means you’re treating a cross-participant exchange as if it were internal—misleading and inaccurate.

Modeling Responsibilities with Pools and Lanes

Pools represent participants. Lanes represent roles or departments within those participants.

Each pool owns its internal sequence flows. Each lane owns the activities assigned to it. The responsibility boundary is clear: you don’t model someone else’s internal logic.

For example, in a procurement process, you might have two pools: “Procurement Department” and “Supplier.” The Procurement Department has lanes for “Purchase Request,” “Approval,” and “Order Creation.” The Supplier has lanes for “Order Receipt,” “Fulfillment,” and “Shipment Notification.”

When the Procurement Department sends an order to the Supplier, that’s a message flow from the “Order Creation” lane to the “Order Receipt” lane in the Supplier pool.

This structure prevents the common mistake of “over-owning” the process. You’re not modeling the Supplier’s internal fulfillment process in detail unless you’re building a collaboration diagram that includes it. Even then, you only show what’s relevant to the interaction.

Best Practices for Assigning Responsibilities

1. One pool per participant. Don’t split a participant across multiple pools. It creates confusion about who is responsible.
2. Use lanes to represent roles, not individuals. Lanes are about function, not names. This keeps models scalable and reusable.
3. Label message flows clearly. Use verbs like “Send Order,” “Confirm Receipt,” or “Request Approval” to make the intent obvious.
4. Align message flow direction with the participant’s role. If the Supplier sends a shipment update, the message flow should originate from the Supplier pool, not the Procurement pool.

These rules aren’t arbitrary. They’re based on years of modeling real supply chains, customer service workflows, and financial reconciliation processes. When you follow them, stakeholders can instantly see who does what—and when.

BPMN Collaboration Message Flow Example

Let’s walk through a real-world BPMN collaboration message flow example: a customer order process between a retailer and a logistics provider.

Pool 1: Retailer (with lanes: Order Entry, Payment Processing, Shipment Request)

Pool 2: Logistics Provider (with lanes: Order Receipt, Dispatch, Delivery Confirmation)

Here’s how the message flows work:

1. After payment is confirmed, the Retailer sends a “Shipment Request” message to the Logistics Provider.
2. The Logistics Provider receives the request and sends a “Shipment Confirmed” message back.
3. After dispatch, the Logistics Provider sends a “Delivery Update” message.
4. Finally, the Retailer sends a “Payment Finalized” message upon delivery confirmation.

Each message flow is a clear, one-way communication. No internal logic is shown in the other pool. That’s the power of separation.

Now, if you were to model this as a single process diagram, you’d have to include all the internal steps of both parties. That’s not just messy—it’s impossible to maintain. Collaboration diagrams exist to solve that exact problem.

Common Pitfalls to Avoid

Even experienced modelers fall into traps. Here are the most frequent ones:

• Mixing sequence and message flows across pools. This implies control where none exists. It breaks the model’s meaning.
• Using message flows to represent internal decisions. A message flow should not be used to show a conditional branch. Use gateways and sequence flows inside the pool.
• Overloading a single pool with too many lanes. If a pool has more than 5–6 lanes, consider splitting it into sub-pools or using conversation diagrams to summarize.
• Using generic labels like “Message” or “Send Data.” Be specific. “Send Invoice” is clearer than “Send Message.”

These mistakes don’t just confuse readers—they undermine trust in the entire model. If stakeholders can’t understand who’s doing what, they won’t use the model to drive decisions.

How Shared Responsibilities Are Communicated

Shared responsibilities don’t mean shared ownership of every step. They mean shared accountability for outcomes.

For example, in the retailer-logistics interaction, both parties are responsible for on-time delivery—but the Retailer is responsible for accurate order data, and the Logistics Provider is responsible for dispatch timing.

That’s where message flows become powerful. They make the handoff points visible. Each message flow is a checkpoint: “This task is complete. Now it’s your turn.”

When you see a message flow labeled “Order Confirmed,” you know the Retailer has finished their part. The Logistics Provider can now begin theirs.

This transparency is the first step toward optimization. You can now measure handoff times, identify bottlenecks, and assign SLAs.

Without message flows, these handoffs are invisible. The process looks like one long chain, and no one knows where delays occur.

Using Message Flows to Define SLAs and KPIs

Message flows are not just for documentation. They’re the foundation for performance measurement.

For example, you can define a KPI: “Time from ‘Shipment Request’ to ‘Shipment Confirmed’ must be under 2 hours.” That’s measurable because the message flow defines the start and end points.

Similarly, “Delivery Update” must be sent within 15 minutes of dispatch. That’s a clear, traceable target.

These KPIs can’t be derived from internal sequence flows alone. They require the external visibility that message flows provide.

Tooling Tips: Visual Paradigm and BPMN Message Flows

Visual Paradigm makes it easy to model message flows correctly. The tool enforces the separation between sequence and message flows, so you can’t accidentally connect two pools with a sequence flow.

When you drag a message flow, it automatically appears as a dashed line with an arrow. The tool also lets you define message types and interfaces—critical for consistency.

Use the “Link to Process Diagram” feature to connect a collaboration diagram to its underlying process diagrams. This way, you can drill down from a high-level message flow to the internal logic of each participant.

Also, use the “Participant Reuse” feature. If you’re modeling multiple order processes, you can reuse the same Retailer and Logistics Provider pools across diagrams. This ensures naming consistency and reduces errors.

Conclusion

Mastering BPMN message flows is not about syntax—it’s about clarity of responsibility.

When you model interactions between pools, always ask: “Who owns this step? What is being communicated? And where does the responsibility shift?”

Use message flows to answer those questions. They’re not just connectors—they’re accountability markers.

With clear pools, lanes, and message flows, you’re not just drawing a diagram. You’re building a shared understanding of how work actually gets done across boundaries.

That’s the real power of BPMN collaboration modeling.

Frequently Asked Questions

Can I use message flows inside a single pool?

No. Message flows are strictly for inter-pool communication. If you need to show internal handoffs, use sequence flows within the pool. Using message flows inside a pool breaks the modeling convention and confuses readers.

What’s the difference between a BPMN collaboration message flow example and a choreography diagram?

A collaboration diagram shows the overall interaction between participants, including both message flows and the internal logic of each. A choreography diagram focuses only on the message exchanges, without showing internal process steps. Use collaboration diagrams when you need to show both sides of the story. Use choreography when you want to define a contract or interface.

How do I handle bidirectional communication in BPMN message flows?

Use two message flows—one in each direction. For example, “Send Order” from Pool A to Pool B, and “Confirm Order” from Pool B to Pool A. Never use a single bidirectional line. BPMN requires separate flows for each direction.

Why should I avoid mixing sequence and message flows between pools?

Mixing them implies that one participant controls the other’s process, which is rarely true. It creates a false sense of ownership and makes the model inaccurate. Message flows are passive signals; sequence flows are active control. Keeping them separate preserves the integrity of the model.

How do I model shared responsibilities without overloading the diagram?

Use lanes to assign specific roles within each pool. Then, use message flows to show handoffs. Keep internal logic detailed only where necessary. For high-level views, use conversation diagrams to summarize interactions.

Can message flows be used in non-executable models?

Absolutely. Message flows are valid in descriptive models used for analysis, documentation, or stakeholder alignment. They’re not dependent on execution. Their purpose is to clarify communication and responsibility—regardless of whether the process is automated.