BPMN Sub Processes

Week 1.5

Previous Post

Automating BPMN Workflows in Camunda with Zeebe Python Client

Which do you think is easy? Designing a large BPMN model or making everyone feel lost? You’re right, both are equally easy. :)

As BPMN models get bigger, they tend to become hard to comprehend, much like software projects. This is why, like in software development, it is worth the time thinking about organizing models in a modular fashion - and to do so, BPMN provides “Sub Processes”.

What Are Subprocesses and Why Use Them?

Subprocesses are perhaps analogous to functions in programming – they help you organize complex logic into manageable, reusable components. When you see a rectangle with a '+' sign in a BPMN diagram, that's a collapsed subprocess waiting to reveal its details. Like functions or classes do, sub processes can help:

1. Simplify Complex Processes: Hide implementation details when they're not needed to be seen

2. Enable Reusability: Define once, use anywhere

3. Support Different Audiences: Business stakeholders can view high-level flows while technical teams can go into details

4. Standardize Operations: Create consistent handling of common business scenarios

Real-World Example: Refund Request Process

Here’s a practical example. At its highest level, a refund process might look deceptively simple, for example:

1. Check Refund Eligibility

2. Process Refund

like in the BPMN diagram below.

But each of these steps contains crucial business logic.

Eligibility Check Subprocess

This might include:

• Verify order exists

• Check refund window

• Validate refund reason

• Review customer history

• Assess fraud risk

The following doesn’t model all of them, but you get the idea.

Refund Processing Subprocess

This might include:

• Calculate refund amount

• Process payment reversal

• Send customer notifications

• Update accounting records

and here’s a simplified model.

The following are some aspects above sub processes embody, right? That is to ensure readability, and maintainability, you need to:

1. Keep it Focused: Each subprocess should handle one specific business capability

2. Maintain Independence: Subprocesses should work with clearly defined inputs and outputs

3. Consider Reusability: Design subprocesses that could be useful in other scenarios

4. Don't Over-Fragment: Not every small group of tasks needs to be a subprocess

and that’s the advantage sub processes bring.

Limitations of sub processes

While subprocesses are powerful, BPMN 2.0 specification states what can and can’t be done in different types of sub processes:

• Regular (Embedded) Subprocess:

  • Can have multiple start events

  • Can have multiple end events

  • Can have different types of start events (timer, message, etc.)

  • Can have different types of end events (error, terminate, etc.)

• Event Subprocess:

  • Must have a single start event

  • Can have multiple end events

  • Start event must be an event trigger (message, timer, error, etc.)

  • Cannot have normal start events

• Call Activity (Reusable Subprocess):

  • The called process can have multiple start and end events

  • How start events are handled depends on implementation (e.g., Camunda)

In conclusion, when designing subprocesses, think about who needs to see what, and keep reusability in mind. Business stakeholders might only need the high-level view(like the very first model), while implementation teams need the details.

---

Note: This post provides a high-level overview of BPMN subprocesses. For a more detailed explanation, refer the Camunda article “Sub Processes” or the ebook Real Life BPMN.