Overloaded Diagrams: Too Much on One Canvas

Too much detail in BPMN turns a clear business process into a visual maze. I’ve seen diagrams that span multiple screens, where a single flow contains 50+ activities, decision points, and exceptions. The result? A model that no one can read, maintain, or trust. This isn’t just clutter—it’s a source of misunderstanding, rework, and failed automation. The root issue? A single diagram trying to represent too many scenarios, responsibilities, or levels of detail.

My experience has taught me that a well-structured BPMN model should be readable at a glance. If you need to zoom in to see what’s happening, or if your eyes are jumping from one corner to another, the diagram is overloaded. The fix isn’t adding more labels or better colors—it’s rethinking the structure.

This chapter lays out practical, field-tested techniques for splitting large BPMN models without losing context. You’ll learn how to use sub-processes, levels of detail, and linked diagrams to keep your processes focused, scalable, and executable. You’ll also discover how BPMN diagram refactoring is not a one-time chore—it’s a continuous practice that pays off in clarity and consistency.

The Hidden Costs of Overloaded BPMN Diagrams

When a BPMN diagram tries to do too much, it fails in ways that aren’t always obvious. The model might technically follow the notation rules, but that doesn’t mean it’s useful.

• Loss of clarity: Readers can’t follow the main path. Decision logic gets buried in a sea of activities.
• Increased maintenance burden: A single change may ripple across dozens of steps, increasing the risk of breaking something else.
• Unrealistic expectations: Stakeholders assume the diagram shows reality. When the truth is it’s a mix of scenarios, exceptions, and technical details.
• High risk of errors: The more elements, the more likely a gateway is misconnected, or a loop never terminates.

These problems are especially common when a process is modeled from the ground up without a clear plan. The diagram starts as a simple flow, but over time, new conditions, roles, and exceptions are added—until the canvas is full.

When You Should Split a BPMN Diagram

Not every large process needs to be split. But when you see these signs, it’s time to act:

• You can’t show the entire diagram on one screen without scrolling.
• There are more than 10 decision points in a single flow.
• Multiple business units or systems are involved, but they’re all in one pool.
• You’re modeling both normal flow and multiple exception scenarios in one diagram.

These are red flags that your too much detail in BPMN has become a liability. The solution is not to shrink the font. It’s to restructure.

Three Fundamental Strategies for Splitting BPMN Models

There’s no one-size-fits-all approach. But three strategies have consistently worked in real-world projects:

1. Use Sub-Processes for Internal Detail

Group related activities under a collapsed sub-process when the internal logic is complex but not critical to the high-level view.

For example, a “Credit Check” activity can be a sub-process that includes:

• Verify credit score
• Check payment history
• Review outstanding debt
• Apply risk rating

Keep the main process focused on the business outcome: “Approve or decline loan.” This is BPMN diagram refactoring at its most practical.

2. Apply Levels of Detail (LoD) for Different Audiences

Not every stakeholder needs the same level of detail. A business analyst might need a high-level view. An IT developer needs step-by-step logic.

Use a two-tier approach:

• Level 1 (High-level): Shows only major phases, decision points, and handoffs.
• Level 2 (Detailed): Expands key sub-processes into full diagrams.

Label each with a version or LoD tag. This allows different teams to access the right view.

3. Use Linked Diagrams for Scenarios and Variants

When multiple paths exist—such as credit approval, rejection, and escalation—don’t try to fit them into one flow.

Create separate diagrams:

• Main Process: Normal approval flow
• Sub-Process: Credit Review: Full credit check logic
• Exception Flow: Escalation: How to handle failed checks

Connect them using a call activity or choreography link. This keeps the main process clean and reusable.

How to Refactor a Large BPMN Diagram: A Step-by-Step Guide

Refactoring isn’t about rewriting from scratch. It’s about organizing intelligence that already exists.

1. Map the current scope: Identify all primary activities, decision points, and exceptions.
2. Group by theme: Cluster activities that belong together—e.g., “Underwriting,” “Risk Assessment,” “Customer Onboarding.”
3. Choose the right container: Use sub-processes for internal logic, call activities for reusable flows, or separate diagrams for distinct scenarios.
4. Define clear boundaries: Each new diagram should have a clear start (e.g., “Risk Approval Request Received”) and end (e.g., “Risk Rating Finalized”).
5. Link with context: Add a brief description and reference to the parent process.

Example:

Original: One diagram with 30+ activities, including credit checks, risk scoring, and escalation paths.

Refactored: Three diagrams:

• Main Process: “Loan Approval Flow” (high-level)
• Sub-Process: “Credit Risk Assessment” (detail)
• Separate Diagram: “Escalation to Senior Review”

The new structure is easier to validate, review, and automate.

Best Practices: What to Avoid

Here are common mistakes that undermine refactoring:

• Creating too many nested sub-processes: Depth beyond two levels makes it hard to follow.
• Overusing call activities: If every task is a call, you lose the operational context.
• Forgetting to document the hierarchy: Without clear labels, readers don’t know which diagram is the “top” level.
• Mixing levels in one diagram: Don’t show a high-level process next to a detailed technical workflow.

Keep it simple. If a diagram has more than 15–20 visible activities, consider splitting it.

Table: Choosing the Right Splitting Technique

Use Case	Best Practice	Example
Internal logic too complex	Use collapsed sub-process	Credit check step as a sub-process
Multiple business scenarios	Create linked diagrams	Approve vs. Reject paths
Reused process across multiple flows	Use call activity	“Customer Verification” used in 3 flows
High-level overview needed	Apply Level of Detail (LoD)	Diagram A: High-level; Diagram B: Detailed

Frequently Asked Questions

How do I know if my BPMN diagram is too large?

If you need to scroll in multiple directions, use a zoom level below 50%, or can’t explain the process in one sentence, it’s likely overloaded. Aim for fewer than 15–20 visible activities on screen.

Can I split a process across multiple pools?

Yes, but only when there are clear handoffs between organizations or departments. Use message flows to connect them. Avoid spreading one business process across multiple pools without a valid boundary.

What happens to the original diagram after splitting?

Keep it as a “master” or “summary” diagram. Use it to reference the child diagrams. Document which sub-processes are expanded where, and maintain version control.

Is it okay to have multiple diagrams for the same process?

Yes—when each serves a different audience or purpose. A business owner needs a high-level view. A developer needs the detailed flow. Just ensure they’re linked and consistent.

How do I prevent my team from creating overloaded diagrams in the future?

Implement a modular modeling standard. Define rules like: “No diagram should have more than 20 activities.” Use model reviews to check for LoD alignment. Train teams to use sub-processes and call activities early.

What if my tool doesn’t support sub-processes or call activities?

Use a tool that does. Most modern BPMN tools (e.g., Visual Paradigm) support these features. If your tool doesn’t, consider upgrading. A poorly supported tool creates more problems than it solves.

Key Takeaways

Overloaded BPMN diagrams are not just messy—they’re dangerous. They hide flaws, confuse stakeholders, and make automation nearly impossible. The real solution isn’t more effort—it’s smarter structure.

Use sub-processes for internal logic, levels of detail for different audiences, and linked diagrams for multiple scenarios. This is splitting large BPMN models done right.

When in doubt, ask: “Can someone unfamiliar with this process understand it in under 90 seconds?” If not, it’s time to split, simplify, and restructure. The diagram you create today will be the blueprint your team follows tomorrow.