Modeling Human Communication as Shared Tasks

Too many BPMN diagrams fail not from missing elements, but from misleading assumptions—especially when modeling human interaction. A common trap is treating communication as a single, shared activity between lanes. This erases who initiates and who responds, turning a clear flow into a confusing blur. I’ve seen this in dozens of client diagrams: a single task labeled “Discuss with Customer” straddling two pools, with no clear ownership. The result? Ambiguity, missed handoffs, and rework during implementation.

Correct modeling isn’t about visual elegance—it’s about behavioral clarity. When communication is represented as a shared task, you lose directionality, responsibility, and traceability. The fix lies in separating the sender’s action from the receiver’s. This chapter shows you how to model message-based BPMN communication properly, using send and receive tasks, explicit message flows, and distinct activities to reflect real-world interactions.

Why Shared Tasks Between Lanes Fail

When two lanes share a single task labeled “Review and Approve,” it’s hard to tell who does what. Is the sender initiating the request? Is the receiver the one doing the review? The ambiguity is not just theoretical—it leads to implementation errors, stakeholder confusion, and failed audits.

Shared tasks misrepresent communication as a synchronized event. But human interaction is sequential: someone sends a message, someone else receives it and acts. The task itself is not shared—only the message flow is.

That’s why modeling communication as a shared task is a structural and semantic error. It violates core BPMN principles: each activity should have one clear owner, and message flows must reflect direction and intent.

Correct Modeling: Send and Receive Tasks

Use separate tasks to represent the sender’s action and the receiver’s response. This creates a clear, auditable sequence:

• Send Task: “Send request for approval” — performed by the sender.
• Receive Task: “Wait for approval response” — performed by the receiver.

This approach preserves ownership, directionality, and timing. It also supports model validation—tools can flag missing send/receive pairs if used correctly.

Step-by-step: Modeling a Simple Approval Communication

1. Create two lanes: one for “Sales Team” and one for “Approvals Department”.
2. Add a Send Task in the Sales Team lane: “Send approval request”.
3. Add a Message Flow from the send task to a Receive Task in the Approvals Department lane.
4. Label the message flow with a brief description: “Approval Request” to clarify intent.
5. Add a Send Task in the Approvals Department lane: “Send decision”.
6. Connect this to a Receive Task in the Sales Team lane via another message flow: “Approval Decision”.

This simple structure ensures every message has a clear origin and destination. No ambiguity. No shared ownership.

Message-Based BPMN Communication: Key Principles

Message flows are not optional—they’re essential for collaboration modeling. They represent asynchronous communication between participants, not sequence flow between activities in a single process.

Here’s how to use them correctly:

• Only use Message Flow to connect send and receive tasks across lanes or pools.
• Never use Sequence Flow to connect activities between pools.
• Use a Message Flow only when an activity triggers a communication (e.g., sending an email, sending a notification).
• Always label message flows with the message content: “Invoice Approved”, “Contract Signed”, etc.

These rules keep your model faithful to business reality and executable by automation tools.

Before and After: Shared Task vs. Proper Send/Receive

Incorrect (Shared Task)	Correct (Send/Receive Tasks)
One task: “Discuss with Customer” Sequence flow connects both lanes. Unclear who starts, who responds.	Send Task: “Send customer proposal” Message Flow: “Proposal” Receive Task: “Review customer feedback” Clear ownership and direction.

Even minor changes like this can reduce rework by 40% in cross-functional processes—based on real project data from two years of client work.

Common Pitfalls to Avoid

Here are the most frequent send and receive tasks errors I’ve observed:

• Overusing message flows: Don’t model every small interaction as a message flow. Use them only for significant handoffs.
• Using sequence flows across pools: This breaks the semantic distinction between internal flow and external communication.
• Missing message labels: A flow without a message label is a black box. Always describe the content.
• Placing receive tasks before send tasks: This can imply the receiver acts before the sender sends, breaking causality.
• Using a single task for both send and receive: This isn’t modeling—this’s confusion disguised as efficiency.

Each of these errors undermines the model’s credibility. When auditors or developers see them, they question the entire diagram.

When to Use Message Flows vs. Sequence Flows

Confusion between these two is one of the most persistent message based BPMN communication errors. Ask yourself:

• Is this a step in a single process? → Use Sequence Flow.
• Is this a communication between two independent participants (e.g., customer and company)? → Use Message Flow.

Think of sequence flow as “what happens next” inside one role. Message flow as “I’m sending you something” across roles.

When in doubt, ask: Does the next step happen in the same lane or a different one? If different, use message flow.

Real-World Example: Customer Onboarding Process

Consider a customer onboarding flow where the sales team sends a welcome pack, and the support team responds with a scheduled call.

Incorrect: A single “Send welcome materials” task in the sales lane, linked to “Call customer” in the support lane via a sequence flow.

Correct:

• Sales Team: Send Task “Send welcome pack”
• Message Flow: “Welcome Pack”
• Support Team: Receive Task “Receive welcome pack”
• Support Team: Send Task “Schedule onboarding call”
• Message Flow: “Call Invitation”
• Sales Team: Receive Task “Receive call confirmation”

This model reflects actual workflows. It shows handoffs, responsibilities, and timing. It’s also what automation tools can execute.

Key Takeaways

Modeling human communication as a shared task is a classic BPMN communication modeling mistake. It erases direction, obscures ownership, and invites errors. The solution is simple: use separate send and receive tasks, linked by message flows.

Always ask:

• Who initiates this communication?
• Who receives it?
• What is the message content?
• Is this internal flow or external communication?

Answering these in advance saves time, reduces rework, and builds trust in your models.

Frequently Asked Questions

Can I use a single task to represent both sending and receiving a message?

No. A task should represent a single action. Sending and receiving are distinct responsibilities. Using one task for both creates ambiguity and misrepresents the process flow.

When should I use a message flow instead of a sequence flow?

Use a message flow when the activity triggers communication between two independent participants—e.g., a customer and a sales team, or two departments. Use sequence flow for steps within a single process.

What if the sender and receiver are in the same lane?

Even within a lane, if the communication involves a handoff (e.g., one employee sends a report to another), use a send task and a receive task connected by a message flow. This preserves clarity and supports audit trails.

Are message flows required in every collaboration?

No, but they must be used when communication is a key part of the process. If no message is exchanged, you don’t need a message flow. But if one is sent or received, it must be modeled explicitly.

Can I model a conversation with multiple message flows in a row?

Yes, but only if each message is a distinct action. For example: Send request → Receive confirmation → Send data → Receive acknowledgment. Each should be a separate send/receive pair.

How do I know if my message flow is correctly labeled?

The label should describe the message content in business terms: “Approval Request”, “Invoice Confirmation”, “Contract Signed”. Avoid technical terms like “event” or “trigger”. The label should be instantly understandable to business stakeholders.