Wrong Level of Detail: Too High, Too Low, or Mixed

Too many modelers start with a blank canvas and assume they must capture every click, every field, every state change. That’s the trap. I’ve seen diagrams so overloaded with technical steps that even the business analyst can’t find the actual decision points. On the other end, I’ve reviewed models so abstract—“Process starts” → “Process ends”—that no one can tell what’s really happening.

These are not just aesthetic issues. They’re communication failures. The wrong level of detail breaks trust. A diagram that’s too deep confuses stakeholders; one that’s too shallow hides critical logic. The result? Misunderstandings, rework, and automation failures.

This chapter cuts through the noise. You’ll learn how to choose the right BPMN detail level based on context and audience. We’ll show how to fix mixed-level diagrams, simplify overly complex models, and rebuild abstract ones for clarity. You’ll walk away with a structured approach that turns vague or messy diagrams into trustworthy, executable models.

Why Level of Detail Matters in BPMN

Every BPMN diagram serves a purpose. That purpose determines its level of detail.

Modeling a customer onboarding process for executives? Focus on key milestones: application submission, eligibility check, document upload, approval. No need to show every button click or error validation.

But if you’re handing this to developers to implement, you need to break down the “eligibility check” into conditions: “credit score > 650”, “residency status verified”, “no fraud flags”. That’s where detail becomes essential.

Here’s the truth: no single level fits all. A model meant for stakeholder review cannot function as a technical blueprint. Confusing the two leads to wasted time, rework, and frustration.

Common Patterns of Misjudged Detail

Too abstract BPMN models often use generic labels like “Process data”, “Handle request”, or “Complete task”. They may skip decision points or merge multiple steps into one. This makes it impossible to verify whether all scenarios are covered.

Over detailed BPMN diagrams include system-level actions: “Click ‘Submit’ button”, “Validate field X against regex”, “Call API /v1/verify”. These are not business events—they’re implementation artifacts. They don’t belong in a BPMN model intended to represent business intent.

When both extremes appear in one diagram, you have a mixed-level mess. A step like “Approve Application” might be split into “Click Approve button”, “Submit form”, “Wait for confirmation” — but the next step is “Review applicant’s background”, which is high-level. This inconsistency breaks flow and confuses everyone.

Choosing the Right BPMN Detail Level

There’s no universal rule. But there’s a framework. Use this decision tree to guide your modeling choices.

1. Who is the audience? Executives? IT teams? Audit teams? End users?
2. What’s the goal? Communicate scope? Enable automation? Document compliance?
3. What’s the process stage? Strategy? Design? Implementation? Audit?

Let’s break it down.

For Executive or Strategic Review

Use high-level models with 5–7 key activities. Focus on value streams, handoffs, and outcomes.

Example: A customer onboarding process might be summarized as:

• Application Received
• Eligibility Check
• Document Verification
• Approval / Rejection
• Onboarding Completion

Use call activities to represent complex subprocesses. No internal detail needed.

For Technical or Implementation Use

Decompose high-level steps into granular, executable tasks. Include decision points, exception flows, and system interactions.

Example: “Eligibility Check” becomes:

• Verify credit score (> 650?)
• Check employment history (≥2 years?)
• Validate ID and address match
• Run fraud risk assessment
• Make eligibility decision

Use gateways to model decision logic. Show alternate paths for rejection, fraud flags, or incomplete data.

For Collaboration or Cross-Functional Alignment

Use detailed models to align departments. Show ownership, handoffs, and communication flows.

Example: The “Document Verification” step might involve:

• Bank sends documents via secure portal
• Compliance team reviews documents
• Requests missing items via message flow
• Updates status when complete

Use message flows to show communication between departments. Keep the focus on responsibility and timing.

How to Re-Level a Diagram

When you inherit a model that’s either too abstract or too detailed, don’t start over. Re-level it systematically.

Step 1: Audit the Audience and Purpose

Ask: Who will use this? What are they trying to do? Is the goal to explain, implement, or audit?

If the model is for a compliance audit, you need full traceability. If it’s for a sprint planning meeting, focus on user stories and outcomes.

Step 2: Identify Mixed Levels

Scan the diagram. Look for:

• One step labeled “Submit form” followed by “Click Submit button”
• “Approve” next to “Verify identity via ID check”
• A step labeled “Process” that includes technical verbs like “call”, “validate”, “retrieve”

These are red flags. They signal a mix of business and technical levels.

Step 3: Group and Refactor

Group related activities into subprocesses. Use call activities to reference reusable logic.

Example:

Subprocess: Verify Identity
- Check government ID
- Match photo to applicant
- Confirm expiration date

Replace “Verify identity via ID check” with a call activity pointing to this subprocess.

Step 4: Apply the 80/20 Rule

Focus on the 20% of steps that drive 80% of the outcome. Remove low-impact steps that don’t affect decision-making or handoffs.

Ask: “Would removing this step change the process outcome?” If no, it may be unnecessary detail.

Decision Matrix: What Level to Use

Here’s a quick reference for choosing detail based on context.

Purpose	Audience	Recommended Detail Level
Strategic planning	Executives, board	High-level, 5–7 steps
Process improvement	Business analysts, process owners	Medium, includes decisions, exceptions
System implementation	Developers, testers	Low-level, includes system actions, logic
Compliance or audit	Internal audit, regulators	Medium to low, with traceability
Training or onboarding	New hires, cross-functional teams	Medium, with clear labels and flows

Best Practices for Consistent Detail

Here’s how to maintain consistency across your models.

• Use call activities for reusable logic: Never repeat a subprocess in multiple diagrams. Use a call activity to reference it.
• Label steps with verb-object structure: “Review application” not “Process review”.
• Keep gateways simple: Use clear, business-friendly conditions. Avoid technical logic like “if field X is not null”.
• Document assumptions: Add annotations for edge cases or rules not captured in the diagram.
• Use consistent terminology: If you call it “approval” in one diagram, don’t call it “sign-off” in another.

Frequently Asked Questions

What’s the difference between too abstract BPMN models and over detailed BPMN diagrams?

Too abstract models hide decision points and miss critical logic. They use vague labels like “handle request” or “process data”, making them useless for implementation. Over detailed diagrams include technical steps like “click submit button” or “call API endpoint”, which are not business events and break the model’s intent.

How do I know if my BPMN model is at the right level of detail?

Ask: “Would someone unfamiliar with the process understand this from the diagram alone?” If not, adjust. Test with your target audience. If stakeholders ask “what happens next?” too often, it’s too abstract. If they say “that’s not how it works”, it’s likely too detailed.

Can I have multiple levels of detail in one BPMN diagram?

Not in a single view. Mixing levels confuses readers and breaks the model’s integrity. Instead, use subprocesses to represent detailed logic. Reference them with call activities. This preserves the high-level flow while allowing drill-down when needed.

How should I model a process that’s both business and technical?

Model the business process first. Then, create a separate technical view if needed. Use DMN to model logic, and link it to BPMN. Never embed technical steps like “call API” in a business process diagram. That’s a modeling error that undermines credibility.

What’s the best way to re-level an existing BPMN diagram?

Start by identifying the audience and purpose. Then, audit for mixed levels. Group activities, use call activities for repeated logic, simplify labels, and remove system-level actions. Keep the core flow clear and aligned with business intent.

Should I use the same level of detail for every process in my company?

No. Different processes serve different purposes. Use high-level models for strategy, medium for operations, and low for systems. The key is consistency in how you apply level of detail, not the level itself.