Misrepresenting Cross-Department Collaboration

When departments share a lane in a BPMN diagram, ownership dissolves into ambiguity. That’s not collaboration — it’s confusion disguised as teamwork. The core principle? Each department must have its own lane or pool. No exceptions. This rule prevents shared responsibility from becoming shared blame.

Too many models use a single lane labeled “Finance & HR” or “Operations Team.” This may look efficient, but it erases accountability. When a task like “Approve Expense” appears in a shared lane, who owns it? Is it the Finance team? HR? A shared duty? That uncertainty ruins auditability and blocks automation.

My advice? Start with the business reality: if two departments act independently, they need separate lanes. You’ll save hours of rework, reduce miscommunication, and create models that actually reflect reality. You don’t need complex diagrams to be clear — just honest structure.

Why Misusing Lanes for Departments Is a Critical Error

Using a single lane for multiple departments violates BPMN’s fundamental purpose: to make roles and handoffs explicit. When teams are crammed together, the model becomes a black box where actions are performed but ownership is invisible.

Consider this real-world example: a loan approval process where “Credit Analyst” and “Risk Manager” both belong to the same lane. The handoff between them looks seamless — but in reality, the risk team often operates with different priorities, timelines, and escalation paths. Blending them creates a model that’s accurate in form but useless in practice.

Here’s the trade-off: separating lanes adds visual complexity, but it delivers clarity. A well-structured collaboration diagram should be easy to follow by someone unfamiliar with the process.

Red Flags of Misused Lanes

• A single lane contains multiple roles from different departments.
• Labels like “Team A & B” or “Shared Tasks” appear instead of specific roles.

Correcting Collaboration: Lanes, Pools, and Message Flows

The fix is straightforward: assign each department its own pool or lane. Use pools for external partners (e.g., Customer, Vendor) and lanes within a pool for internal departments.

Every handoff must be either a sequence flow (within a pool) or a message flow (between pools). Message flows are mandatory for cross-department communication. They visually signal that one department sends information to another — and that message triggers the next step.

Let’s say Finance needs to approve an invoice before HR processes payroll. In a corrected model:

1. Finance has its own lane.
2. “Review Invoice” is in the Finance lane.
3. A message flow labeled “Approved Invoice” goes to HR.
4. HR’s “Process Payroll” starts only after receiving that message.

This makes the dependency clear, the trigger visible, and the responsibility unambiguous.

Best Practices for Modeling Departmental Collaboration

Use this checklist when modeling cross-department collaboration:

• Assign every department its own lane or pool.
• Never use a single lane for multiple business units.
• Use message flows to show communication between departments.
• Label message flows with clear, business-friendly descriptions (e.g., “Send Approval Request”).
• Ensure every message flow has a corresponding receiving task.

Common Pitfalls and How to Fix Them

Even when you separate lanes, mistakes creep in. Here are the most frequent ones and how to avoid them.

Pitfall 1: Overusing Sequence Flows Between Pools

Sequence flows are for internal process steps. Using them between pools implies a direct control flow — but departments don’t control each other’s actions. They communicate via messages.

Fix: Replace sequence flows with message flows. This enforces the correct model: one department sends a message, the other responds.

Pitfall 2: Invisible Handoffs

Some models show a task in one department ending and a task in another starting — but no flow connects them. This creates a “ghost” handoff, where the workflow seems to continue, but no mechanism triggers the next step.

Fix: Always use a message flow to link the end of one task to the start of another. Even if it’s a simple “next step” message, it must be visible.

Pitfall 3: Ambiguous Message Content

Labeling a message flow as “Send Data” or “Pass Info” is worse than no label at all. It tells no one what’s being sent or why.

Fix: Use specific, outcome-based language. Examples:

• “Send Approved Budget Proposal”
• “Notify Finance: Payment Request Ready”
• “Forward HR Onboarding Form to Payroll”

Real-World Example: Rebuilding a Broken Process

Here’s a before-and-after look at a real case I audited.

Before: Shared Lane, Confused Handoff

• Lane: “Finance & HR”
• Tasks: “Review Expense,” “Approve,” “Process Payroll”
• Sequence flows connect all tasks.
• No message flows.

Result: When asked who approves payroll, no one could say. The model implied HR did — but Finance had to approve first.

After: Clear Pools with Message Flows

• Pools: “Finance” and “HR”
• Finance lane: “Review Expense,” “Send Approval to HR”
• Message flow: “Approval Received” from Finance to HR
• HR lane: “Process Payroll” — starts after message.

Result: The model now reflects reality. The handoff is explicit. Auditors can trace the chain. Automation teams can build the correct triggers.

Key Takeaways

Clear collaboration begins with structure. Never merge departments in one lane. Always use separate pools or lanes, and always use message flows to represent handoffs.

cross department BPMN mistakes aren’t just about bad layout — they’re about eroding accountability. A good model shows who does what, when, and how they’re connected.

When you model collaboration correctly, you’re not just creating a diagram. You’re creating a contract between teams.

Frequently Asked Questions

Should I always use separate pools for every department?

No — if a department is a single team with a unified role (e.g., “Customer Support”), one lane suffices. But if multiple departments (e.g., Sales, Marketing, IT) are involved in a process, each must have its own lane or pool.

Can I use message flows inside a single pool?

Yes, but only when modeling communication between different roles within the same organization. For example, “Send Report to Manager” in the “Finance” lane uses a message flow because it’s a handoff between roles.

What’s the difference between message flow and sequence flow?

Sequence flow shows control flow within a process. Message flow shows communication between separate processes or pools. Use sequence flow for internal steps. Use message flow for external or inter-role handoffs.

How do I handle a department that doesn’t have a dedicated lane?

If a team is small and only contributes minimally, you can include them in a larger lane. But if they make decisions or perform actions that affect the process, separate them into their own lane.

Can I reuse a message flow across multiple scenarios?

Yes, but define it once in a message flow catalog or documentation. Avoid repeating the same message in multiple places unless it’s a standard, widely accepted pattern.

Why is BPMN handoff clarity so important for automation?

Automation tools rely on clear triggers. A message flow is a trigger. If handoffs are unclear, the system can’t know when to execute the next step — leading to delays, errors, or failed workflows.