Combining Multiple Processes into One Diagram

Too many modelers begin with the assumption that one diagram can capture an entire business journey, no matter how many distinct processes are involved. This leads to a single, sprawling diagram that becomes a tangled web of tasks, gateways, and message flows. The result? A model that fails to communicate clearly, resists maintenance, and misleads both technical and business stakeholders.

My own experience with enterprise-scale process modeling taught me that complexity is not the same as completeness. A diagram that tries to show everything often shows nothing well. The real issue isn’t the number of processes—it’s the failure to recognize when each process is a distinct, self-contained flow with its own scope, actors, and lifecycle.

When you merge multiple processes into one BPMN diagram, you’re not simplifying—you’re creating a multi-process confusion that undermines the entire purpose of BPMN: clarity and precision. This chapter will guide you through why this mistake happens, how to identify it, and—most importantly—how to fix it with sound, scalable modeling principles.

You’ll learn when to use separate BPMN diagrams for scenarios, how to link processes without losing context, and how to maintain a seamless end-to-end view without sacrificing readability.

Why One Diagram Isn’t Always Enough

Every process has a boundary. That boundary defines what’s in scope and what’s not. When you merge two processes—one for customer onboarding and another for account verification—into a single diagram, you blur that boundary and create ambiguity.

Consider this: a customer submits an application. That’s one process. The bank then reviews the documents. That’s another. The verification step involves different people, different timelines, and different triggers. Trying to model both in one diagram forces you to mix responsibilities, hide handoffs, and create a flow that’s impossible to validate.

Here’s a rule I’ve used for years: if your diagram includes more than three distinct actors or spans more than 30 elements without a clear hierarchy, it’s a red flag. You’re overloading the BPMN canvas, which defeats the purpose of modeling in the first place.

The goal isn’t to reduce diagrams—it’s to make them meaningful. A single process should represent a coherent business goal, with a clear start, a defined scope, and a measurable end.

How to Identify and Fix Multi-Process Confusion

Not all tangled diagrams are created equal. Let’s walk through how to diagnose whether you’re dealing with multiple processes in one BPMN diagram.

Ask yourself these questions:

• Are there multiple independent triggers (e.g., a customer application and a compliance check) that don’t share a common input?
• Do different teams own different sections of the flow, with no shared decision logic?
• Is there a clear handoff point where one process ends and another begins, but no separation in the diagram?

If yes to any of these, you’ve likely merged processes. The fix is simple: split them into separate diagrams.

Step-by-Step: Splitting BPMN Processes

1. Identify process boundaries based on triggers, ownership, and outcomes. Each distinct goal should have its own diagram.
2. Extract distinct flows into their own BPMN diagrams. Use clear titles like “Customer Onboarding” or “Document Verification”.
3. Use message flows to connect the diagrams when interaction is required. For example, the onboarding process sends a “Document Ready” message to the verification process.
4. Add a collaboration diagram to show the end-to-end journey across all processes. This is not a single diagram—it’s a map of interrelated models.

Let’s look at a real example: a bank’s loan approval workflow.

One modeler combined the application submission, credit check, and approval decision into one diagram. It had 70+ elements, spanning multiple departments, and no clear ownership. When audited, it turned out the credit check was being performed by a third-party system, but the diagram showed it as an internal activity.

We split it into three separate diagrams. The application submission was modeled in one. The credit check was a separate diagram, triggered by a message from the first. The approval decision used the result from the second. Now, each process was clear, auditable, and reusable.

When to Use Separate BPMN Diagrams for Scenarios

Not every variation of a process needs its own model. But when the logic diverges significantly—such as a standard approval versus a high-risk exception—you must separate them.

Here are clear signals that you should use separate BPMN diagrams for scenarios:

• One process has a standard path, and another has a complex exception flow.
• Two processes share a similar start but differ in validation rules, approvals, or timelines.
• One process is triggered by a business event; the other by a system event.

When these distinctions exist, forcing both into one diagram leads to confusion. You’ll find yourself adding extra gateways, annotating paths with “only for high-risk cases,” and eventually losing track of what’s real and what’s conditional.

Instead, model the standard flow as Process A. Model the exception as Process B. Reference Process B from Process A using a message flow or a call activity. This keeps the model modular and maintainable.

Modeling Interactions Without Losing Context

Some worry that splitting processes breaks the end-to-end journey. That’s a myth.

The end-to-end view doesn’t need to be in one diagram. It can be a collaboration diagram that shows how multiple processes interact.

Here’s a practical approach:

• Create a high-level collaboration diagram with pools for each process and message flows showing handoffs.
• Use call activities to invoke a subprocess when a process is reused (e.g., a standard credit check).
• Document each process with a clear description, inputs, and outputs.
• Reference the diagrams in a table or index so users can navigate the full journey.

For example, in a healthcare system, the patient intake process, insurance verification, and lab test scheduling are all separate processes. But they’re linked through message flows: “Patient Data Ready” → “Verification Requested” → “Test Scheduled”.

This way, you preserve the sequence of events without sacrificing clarity.

Best Practices for Managing Multiple Processes

Here’s a checklist I use when reviewing models with multiple processes:

• One process, one diagram. No exceptions.
• Use message flows to show handoffs between processes.
• Define clear inputs and outputs for each process.
• Create a process index that maps all related diagrams and their relationships.
• Use consistent naming like “Process: [Name]” or “Scenario: [Type]”.

For teams, I recommend building a BPMN pattern library that includes standard templates for common processes: onboarding, approval, escalation, verification. This reduces duplication and increases consistency.

Remember: separate BPMN diagrams for scenarios isn’t a sign of fragmentation—it’s a sign of maturity.

Frequently Asked Questions

Can I have multiple processes in one BPMN diagram?

Technically, yes—but it’s a red flag. BPMN is designed for one process per diagram. Multiple processes in one diagram create confusion, violate the principle of scope, and make validation and maintenance nearly impossible.

How do I link separate BPMN diagrams?

Use message flows between pools or call activities. A message flow shows an interaction (e.g., “Verification Approved”), while a call activity references another diagram as a reusable subprocess.

When should I split BPMN processes?

When the process has a different trigger, ownership, timeline, or outcome. If the logic diverges significantly, or if a process is reused in multiple contexts, splitting it improves clarity and reusability.

What’s the difference between splitting processes and using sub-processes?

A sub-process is a containment structure within one process. It’s used to group related steps for readability. Splitting processes means creating separate diagrams for distinct, independent workflows with their own scope.

Can I still show an end-to-end view without merging all processes?

Absolutely. Use a collaboration diagram that shows the sequence of processes via message flows. This view is ideal for stakeholders, while detailed models remain in separate diagrams.

How do I avoid BPMN multi process confusion in my team?

Establish a modeling standard: one process = one diagram. Use a shared repository, enforce naming conventions, and run peer reviews focused on scope and clarity. Training on when to split BPMN processes is essential.