modeling

BPMN Subprocesses: Understand and Organize Your Diagrams

Peter Carter
BPMN Subprocesses: Understand and Organize Your Diagrams

As business processes grow in complexity, subprocesses become essential for maintaining clarity, modularity, and reusability. In this article, you'll learn what subprocesses are in BPMN, when to use each type, and how to apply them effectively

What is a subprocess in BPMN?

A subprocess is a compound activity — in other words, it represents a sequence of grouped tasks that are treated as a single step in the main process. Instead of showing all the activities at once, the model displays only the subprocess block, with details available for those who want to expand or analyze it separately.

Subprocesses help to:

  • Break large processes into more manageable parts;
  • Reuse common logic;
  • Make diagrams easier to read and maintain.

Benefits of using subprocesses

Subprocesses are strategic allies in process modeling because they promote clarity, modularity, and standardization. By organizing a process into smaller, cohesive parts, you improve communication across teams and make the model easier to maintain and evolve over time.

  • Organization: Keeps the main process clean by grouping related activities into blocks.
  • Focus: Allows responsibilities to be split across areas or teams, making delegation and understanding easier.
  • Standardization: Enables consistent reuse of flows that repeat in different parts of the business.
  • Governance: Improves control over critical parts of the process, supporting maintenance and auditability.

Types of BPMN 2.0 Subprocesses

When modeling a business process, it’s common to identify parts that deserve more detail or logical grouping. BPMN 2.0 offers different types of subprocesses for this purpose, each with a specific role. Understanding these variations is essential to represent your process clearly and accurately.

The table below gives an overview of the main types:

Subprocess TypeDescription
Embedded SubprocessDefined and detailed within the main diagram. Can be expanded or collapsed.
Call ActivityCalls an external, reusable process that can be versioned separately.
Event SubprocessTriggered by events like messages, timeouts, or signals.
Ad-Hoc SubprocessFlexible execution without a predefined task order.
Transactional SubprocessRepresents a transaction that can be confirmed or rolled back.

Embedded Subprocess

An embedded subprocess is the most straightforward subprocess in BPMN. It is modeled within the same process diagram, meaning its internal tasks are fully contained within the parent process.

Key characteristics:

  • Part of the main process, with integrated start and end events.
  • Can be represented in two ways:
    • Collapsed: a rectangle with a “+” icon in the center.
    • Expanded: shows all internal tasks directly in the diagram.
  • Ideal for detailing a section of the process without creating a new diagram.
  • Cannot be reused in other processes.

✅ When to use:

  • When tasks are closely related to the main process.
  • To improve diagram readability by grouping related actions.
  • When reuse in other flows is not needed.

Example:

In a "New Customer Registration" process, tasks like verifying documents, validating data, and approving registration can be grouped in an embedded subprocess called "Verify and Approve Customer."


Call Activity: the true "reusable subprocess"

In BPMN 2.0, the official element for reuse is called Call Activity.

💡 What is it?
A Call Activity is an activity that invokes a separate process, which can be reused across different processes or multiple points within the same one.

This is ideal for centralizing recurring subprocesses such as:

  • “Approve Request”
  • “Issue Invoice”
  • “Validate Customer Data”

Benefits of Call Activity:

  • Enables standardization of critical subprocesses across the organization.
  • Supports centralized maintenance: changing the called process updates it everywhere it’s used.
  • Reduces redundancy and logic inconsistency between departments.

Event Subprocess

The Event Subprocess was introduced in BPMN 2.0 (officially released in 2011) and represents a subprocess that is not part of the main sequence flow, but can be triggered when a specific event occurs — such as a message, a time condition, or an error.

🌟 Typical use cases

SituationHow the Event Subprocess applies
Response time exceededTimer Event Subprocess sends notification or escalates.
External message receivedMessage Event Subprocess initiates an alternate flow.
Error occurredError Event Subprocess handles failures appropriately.
Cancellation requestedSignal Event Subprocess reacts to a signal triggered by another process.

⚠️ Interrupting vs Non-interrupting

  • Interrupting: Stops the main process flow when triggered.
  • Non-interrupting: Runs in parallel without affecting the ongoing process.

You can identify this by the start event line:

  • Solid line = interrupting
  • Dashed line = non-interrupting

Example:

In an Approval Process, if no response is received within 5 business days, a Timer Event Subprocess can send an alert to the manager and automatically close the request.

✅ When to use:

  • To handle exceptions, delays, or external events.
  • To model actions that depend on parallel events.
  • When automatic monitoring and response is needed.

Ad-Hoc Subprocess: when task order doesn’t matter

The Ad-Hoc Subprocess is used when internal tasks can be executed in any order, or even optionally, depending on the context or human judgment.

Key characteristics:

  • No explicit sequence between tasks.
  • Activities may be performed partially, fully, or skipped.
  • Ideal for creative, collaborative, or exploratory processes.

✅ When to use:

  • In contexts with no predefined sequence.
  • To model informal or creative workflows.
  • When participants decide what to do, when, and whether to do it.

Example:

In a subprocess called “Plan Corporate Event”, tasks like:

  • Choose venue
  • Define speakers
  • Plan refreshments
  • Design promotional materials

...can happen in any order or simultaneously. The important thing is they’re all done before the event, but the order depends on the team.


Transactional Subprocess: for controlled multi-step operations

The Transactional Subprocess is used when you need to ensure that a group of activities is completed as a unit — either all succeed, or none do. This type of subprocess represents a transaction in the business sense and is useful when you want to model commit/rollback behavior.

Key characteristics:

  • Encapsulates activities that must succeed together.
  • Can be aborted, rolled back, or confirmed using intermediate events.
  • Used in processes that require compensation or error handling if something goes wrong.

✅ When to use:

  • For financial or legal operations where partial completion is not acceptable.
  • When failure of one step requires undoing previous steps.
  • When you want to explicitly model commit/cancel boundaries.

Example:

In a Loan Approval process, you might have a transactional subprocess for “Sign Contract and Release Funds.” If the contract is not signed, any preparations (like reserving funds) must be undone — modeled as a compensation flow.


Best practices when using subprocesses

  • Use subprocesses to group logically related tasks.
  • Prefer Call Activities when the same flow needs to be reused.
  • Use Event Subprocesses to handle exceptions, delays, and interruptions.
  • Name subprocesses clearly using verb + complement: "Review Application", "Register Request".
  • Document called processes in Call Activities — including version, owner, and purpose.

Practical examples

In a “Material Request” process of the image below, the subprocess “Handle Order Picking and Delivery” handles all tasks from item picking to shipping to the requester.

If you expand the subprocess, you can see all internal tasks that make up this flow — providing clarity while keeping the main process concise.

In another example, there are two Call Activities: "Register Suppliers" and "Receive Purchased Goods".

When you navigate to the process behind "Register Suppliers" you can see the entire subprocess flow.

What’s interesting here is that the called process starts with a simple message start event, meaning it can be initiated manually at any time. This adds greater flexibility to the overall design, as the subprocess can also operate independently when needed.

🚀 Explore diagrams with subprocesses

👉 You can access free examples with subprocesses and Call Activities using your free account in the HEFLO BPMN modeler. Click the button below to explore another article packed with real-world BPMN subprocess examples.

Frequently Asked Questions (FAQ) about BPMN subprocesses

What is the main difference between an Embedded Subprocess and a Call Activity?

An Embedded Subprocess is defined and detailed directly within the same diagram, while a Call Activity references a separate process that can be reused in other diagrams.

Can a Call Activity call itself?

No. BPMN doesn't support recursive process invocation. A Call Activity should reference another distinct process.

What happens if an Event Subprocess and the main process run at the same time?

If the Event Subprocess is interrupting, it will stop the main flow. If it’s non-interrupting, it will run in parallel without affecting the main process.

How do I know when to use a Transactional Subprocess?

Use it when the subprocess must be completed entirely or rolled back. It’s ideal for financial, legal, or sensitive operations.

Is an Ad-Hoc Subprocess just a group of tasks?

Not exactly. While it does group tasks, the key distinction is that it doesn’t define a sequence — the execution order is flexible or left to the participants.

Can subprocesses contain other subprocesses?

Yes. BPMN allows nesting of subprocesses. An Embedded Subprocess, for example, can contain another subprocess within it.

Conclusion

Subprocesses are essential for creating clear, structured, and effective BPMN models. By understanding the different options — embedded, event-driven, reusable, ad-hoc, and transactional — you gain the flexibility to represent everything from simple routines to complex exceptions and collaborative flows.

Choosing the right type of subprocess makes the process more understandable for everyone involved and easier to maintain over time. Additionally, good practices around documentation and reuse help standardize and strengthen governance across your business processes.


Enjoyed this? Spread the word!
Related Articles