Tasks, Sub-Processes, and Call Activities Misapplied

Every time I review a BPMN diagram that spans multiple screens, I see the same red flag: a flat, unstructured chain of tasks. This is not a model—it’s a flowchart with baggage. The root of the problem? Misapplying tasks, sub-processes, and call activities. It’s not that these elements are misunderstood—they’re just overused, misused, or ignored.

Let me be clear: a BPMN task should represent a single, atomic unit of work. A sub-process groups multiple tasks into a single activity with a clear boundary. A call activity references a reusable process defined elsewhere. Confusing these leads to diagrams that are hard to read, debug, and maintain.

Over the last 20 years, I’ve watched teams spend weeks cleaning up models that should have been structured properly from day one. The good news? These are correctable. This chapter explains exactly when to use each, how to refactor messy models, and what to avoid. You’ll walk away with a method to build layered, readable processes that stand the test of time.

Understanding the Core Misconceptions

Many modelers assume that everything must be a task. This stems from a misunderstanding of BPMN’s purpose: to represent business processes, not just system steps.

When every activity is a task, you lose all hierarchy. The process becomes a long, monolithic line of work with no natural grouping. This is known as flattened BPMN process issues.

I’ve seen a customer onboarding process with 47 tasks in a single lane. No grouping. No structure. No way to summarize or validate. The modeler said, “It’s all one workflow.” But that’s not how business works. Work is broken into logical chunks—approval steps, document collection, verification checks.

Sub-processes are not just “a bunch of tasks.” They are containers for logic that share a common purpose. Use them to group related activities under a single header, whether that’s Verify Identity, Process Payment, or Review Application.

Why Flat Modeling Fails

Flattened BPMN process issues are not just inconvenient—they’re dangerous. They hide complexity, make validation difficult, and increase the risk of oversight.

• Missing logic becomes invisible in a long chain.
• Reusing common steps across multiple processes becomes impossible.
• Stakeholders can’t grasp the process structure.
• Automation tools struggle to map a 50-task process without clear boundaries.

Think of it like trying to read a book where every chapter is merged into one 500-page block. You lose the sense of progress, and you can’t refer back easily.

When to Use Each Element: A Practical Guide

Let’s clarify what each element is for—and when not to use it.

Use a Simple Task When…

It’s a single, atomic action with no internal logic. The work doesn’t break down further.

• Enter customer name
• Send confirmation email
• Update database record
• Print approval letter

These are perfect for simple tasks. Never group them under a sub-process unless you’re about to add more logic.

Use a Sub-Process When…

You’re grouping multiple related tasks under a single logical block. The sub-process has a clear purpose and can be collapsed for readability.

• Verify customer identity
• Check credit score
• Review past transactions

This is a classic using BPMN subprocess correctly scenario. The sub-process can be collapsed into Review Application—a single node that hides the complexity.

When you use sub-processes, you’re not just organizing—it’s a signal to readers: “This is a self-contained unit. Don’t ask about the steps unless you need to.”

Use a Call Activity When…

The same process logic is reused across multiple areas. It’s a reference to a separate, defined process.

For example, a Verify Identity sub-process might be used in Onboard Customer, Open Account, and Reopen Case. Instead of duplicating it, use a call activity to reference a Verify Identity process.

Call activities are not just for reuse—they’re for clarity. They make it obvious when a process is being reused and where to go to see the full details.

Refactoring a Flattened Process

Let’s walk through a real example.

Imagine a customer onboarding process with 47 flat tasks. One of them is: Check credit bureau report for fraud indicators. It takes five steps: retrieve report, analyze data, flag anomalies, cross-check with internal rules, and report findings.

Instead of leaving this as five separate tasks, group them into a Verify Credit Risk sub-process. Collapse it. Now the main flow reads:

1. Collect customer documents
2. Verify identity
3. Verify credit risk
4. Approve or reject application

The model is now readable. Stakeholders can focus on intent. Developers can drill down when needed.

Before: Flattened BPMN Process Issues

Here’s a simplified version of the original model:

[Start] 
→ Collect documents 
→ Verify identity 
→ Retrieve credit report 
→ Analyze data 
→ Flag anomalies 
→ Cross-check rules 
→ Report findings 
→ Approve or reject
→ [End]

This is a textbook example of flattened BPMN process issues. Each step is a task, and the logic is buried in sequence.

After: Using Sub-Processes and Call Activities

Now restructured:

[Start] 
→ Collect documents 
→ Verify identity 
→ [Call Activity: Verify Credit Risk] 
→ Approve or reject
→ [End]

The Verify Credit Risk call activity links to a separate, named process. It’s reusable, auditable, and scalable.

And inside that model, we can use sub-processes to group logic for analysis and flagging.

Common Pitfalls and How to Avoid Them

BPMN Call Activity Misuse

I’ve seen modelers use call activities for processes that are only used once. That’s a red flag. If a process isn’t reused, don’t make it a call activity. It adds overhead without benefit.

Also, never use a call activity to reference a process that’s already in the same diagram. It breaks transparency. If you need to reuse logic, keep the process separate.

Misusing Sub-Processes

Sub-processes should not be used for every small group of tasks. If you have only two or three steps, ask: Is there a clear business purpose here?

For example: Send email → Log email → Mark as complete. This is not a logical unit. It’s just a sequence. Keep it flat.

But: Review application → Check documents → Verify identity → Check credit history → Make decision. This is a sub-process.

Sub-processes are for grouping work that has a shared intent.

Decision Tree: Choosing the Right Element

Here’s a simple checklist to guide your decisions:

1. Is the work single and atomic? → Use a task.
2. Is the work a group of related steps with a clear goal? → Use a sub-process.
3. Is the same logic used in more than one process? → Use a call activity.
4. Does the sub-process contain more than 5–7 steps? → Break it into sub-sub-processes or use a call activity.

Follow this, and you’ll avoid most BPMN task vs subprocess mistakes.

Frequently Asked Questions

Can I use a sub-process inside a call activity?

Yes—but only if the called process is defined elsewhere. The sub-process is part of the called diagram, not the calling one. Don’t nest sub-processes inside a call activity in the main flow unless the called process is structured that way.

What if my process is too big to fit on one page?

That’s a sign it’s not a single process. Split it. Use a call activity to reference a subprocess that belongs to a different scope. Or, use a collaboration diagram with pools and message flows.

Is it okay to have a sub-process with only one task?

Technically yes, but it’s a red flag. If a sub-process has only one task, why not just use a task? Use sub-processes to group meaningful logic, not to pad structure.

Should I always use call activities for reusable logic?

Yes. If the same sequence of steps appears in multiple processes, make it a call activity. It improves consistency, reduces duplication, and makes changes easier.

How do I know when to collapse a sub-process?

When a sub-process has more than 5–7 steps, or when it’s too complex to describe in one sentence. If stakeholders can’t understand the purpose at a glance, it should be broken down.

Can a sub-process be used for parallel processing?

Yes—use a parallel gateway inside a sub-process to manage concurrent flows. But avoid using sub-processes just to group parallel tasks. Use them when the group has a shared business goal.