Sequence Flows vs Message Flows: Mixing Worlds

Here’s the one thing that changes everything: mixing up sequence flows and message flows is not just a notation error—it’s a semantic betrayal of responsibility. When you use a sequence flow to represent a message between two pools, you erase who’s doing what, and that’s where misunderstandings begin.

For over two decades, I’ve reviewed BPMN diagrams from dozens of organizations. The most persistent flaw? Using sequence flows across pools, or placing message flows inside a single process. These aren’t just style issues—they break the core intent of BPMN: to show who acts, when, and how.

This chapter will clarify the distinction, walk through real examples of how these mistakes manifest, and give you a simple decision rule to follow in any collaboration scenario. You’ll learn when to use sequence flow vs message flow, and how to avoid the most common BPMN flow type mistakes.

Understanding the Core Difference

Sequence flows and message flows serve completely different purposes—and confusing them undermines the entire model.

Sequence flows represent the order of execution within a single process. They show the logical progression from one activity to the next, and are always drawn as solid lines with arrowheads.

Message flows represent communication between two separate participants: two pools, two lanes, or a process and an external agent. They are dashed lines with arrowheads and imply a sender and receiver.

It’s a fundamental split: sequence flows are about internal control flow, message flows are about external communication.

When to Use Each: The Decision Rule

Ask this question: Are both ends of the flow inside the same pool or lane?

If yes → Use a sequence flow. The flow is part of the same process’s execution.

If no → Use a message flow. The action is sent from one participant to another.

There’s no ambiguity. No exceptions. This rule prevents the most common BPMN flow type mistakes.

Common Mistakes and How to Fix Them

Mistake 1: Using Sequence Flows Between Pools

Imagine a process where a customer submits a form, and then the sales team responds. If you draw a sequence flow from the customer’s task to the sales task across two different pools, you’re saying the sales team is executing a step within the customer’s process—which is false.

This misrepresents responsibility and blurs process boundaries. It makes no distinction between execution order and communication.

Fix: Replace the sequence flow with a message flow from the customer’s task to the sales task. This clearly shows that the customer sends a message, and the sales team responds.

Mistake 2: Using Message Flows Inside a Single Process

Now imagine a process with two tasks in the same lane: “Review Application” and “Approve Application.” If you connect them with a message flow, you’re implying that one step sends a message to the other—like they’re separate entities.

But they’re in the same process. The second task is not receiving a message from the first—it’s just the next logical step.

Fix: Use a sequence flow instead. The message flow implies a communication event that doesn’t exist. This preserves the logical flow and avoids confusion.

Mistake 3: Confusing Message Flows with Association Lines

Association lines (dotted lines) are used to link artifacts (like text annotations or data objects) to activities. They should never be used to represent control or message flow.

Using an association to connect two tasks in different pools is a serious error. It’s syntactically invalid and semantically meaningless.

Fix: Only use message flows for communication between pools. Use associations only for linking artifacts to elements.

Real-World Examples

Example: Customer Onboarding Collaboration

Consider a customer onboarding process involving two pools: Customer and Onboarding Team.

Bad: A sequence flow from “Submit Application” (Customer) to “Verify Documents” (Onboarding Team).

Good: A message flow from “Submit Application” to “Verify Documents.”

The message flow makes it clear that the customer sends a message, and the onboarding team receives and acts upon it.

Example: Internal Approval Process

In a single process, a manager must approve a request.

Bad: A message flow from “Review Request” to “Approve Request” in the same lane.

Good: A sequence flow from “Review Request” to “Approve Request.”

The sequence flow reflects the natural, ordered execution within a single business process.

Quick Reference: Flow Type Decision Table

Context	Flow Type	Why
Within a single pool/lane	Sequence flow	Control flow, execution order
Between two different pools/lane	Message flow	Communication between participants
Linking an artifact (e.g., annotation) to an activity	Association (dotted)	Non-execution link
Handoff from one role to another in the same process	Sequence flow	Same process, same flow

Best Practices for Modeling Collaboration

When modeling collaboration, always ask: Who is sending? Who is receiving? Are they part of the same process?

Use message flows to represent interactions between distinct roles. This preserves clarity and ensures the model reflects reality, not illusion.

Never use sequence flows to represent communication across pools. It’s a red flag for poor responsibility modeling.

When in doubt, check your model with a simple test: If you removed the message flow, would the process still make sense? If yes, you’ve likely used the wrong flow type.

Remember: A message flow cannot be used inside a single process to show execution order. If the action is part of the same process flow, use sequence flow.

Why This Matters for Execution

Incorrectly using sequence flows between pools makes it impossible to determine who triggers the next step. Is the customer supposed to initiate it? Is it automatic? Is it a handover?

When automation tools parse these models, they rely on correct flow semantics. A message flow tells them a communication event is expected. A sequence flow tells them the next step is automatic.

Mixing them up leads to failed implementations, incorrect automation, and audit failures.

Final Checklist: Before You Finalize Your Diagram

• Verify all flows between pools are message flows (dashed).
• Confirm all flows within a single pool are sequence flows (solid).
• Ensure no message flows are used inside a single process to represent control flow.
• Double-check that associations (dotted lines) are only for linking artifacts, not activities.
• Use the decision rule: “Same pool? → sequence flow. Different pool? → message flow.”

These checks are not optional. They’re the difference between a model that works and one that misleads.

Frequently Asked Questions

Can I use a sequence flow between two lanes in the same pool?

Yes, but only if the flow is part of the same process execution. If the two lanes represent different roles in the same process (e.g., “Manager” and “HR”), and one hands off to the other, use a sequence flow. But if it’s between two distinct processes (e.g., “HR” and “Finance”), use a message flow.

Why can’t I use a message flow inside a single process?

Because message flows imply communication between separate participants. Inside a single process, tasks are part of the same execution flow. Using a message flow here misrepresents the model and breaks the semantic meaning.

What happens if I mix sequence flow and message flow in the same collaboration?

It creates confusion about responsibility and triggers. The process may become unexecutable, or automation tools may fail to interpret the correct flow. It also violates BPMN semantics and makes the model unreliable for audits or implementation.

Is it okay to use a message flow to show a notification within a process?

No. If a task triggers a notification to another task in the same process, use a sequence flow. Use message flows only when the receiver is a separate participant (e.g., a different pool or external system).

Can I use message flows to represent data exchange?

Only if the data exchange is part of a communication between participants. If the data is passed as input/output within a single process, use sequence flows. Message flows are for communication events, not data transfer.

How do I know if I’m using sequence flows between pools?

Check the ends of the flow. If the two tasks are in different pools or lanes, and you’re using a solid line, you’re using sequence flow incorrectly. Replace it with a message flow (dashed line).

Always double-check your flow types. It’s one of the easiest fixes that has the biggest impact on clarity and correctness.

Mastering sequence flow vs message flow isn’t about memorizing rules. It’s about understanding who does what—and when. When you get this right, your model becomes trustworthy, executable, and truly business-aligned.