Insight · Process modeling

BPMN Sub-Processes, Call Activities and Error Handling in Sparx EA

BPMN gives you three ways to package process logic, and choosing wrong is the difference between a maintainable model and one that drifts. An Embedded Sub-Process lives inside its parent and isn't reusable. A Call Activity references a separate Global Process that several parents can share. An Event Sub-Process is triggered by an event rather than by normal flow. On top of that sit boundary events for error handling and compensation for rollback. This piece covers each, and how to build them in Sparx EA.

The three sub-process mechanisms, side by side

Before the detail, the shape of the decision: the same collapsed rectangle can mean three different things, distinguished by border and behavior.

Same shape, three meanings thin border Embedded not reusable + thick border Call Activity reusable Global Process + dashed border Event Sub-Process event-triggered The border tells the reader how the block behaves before they open it.
Thin border = embedded; thick border = call activity; dashed border = event sub-process.

Embedded Sub-Process

An Embedded Sub-Process is a process within a process — a named group of activities shown expanded (all internal detail visible) or collapsed (just the boundary with a small plus icon). It is contained within the parent and not callable elsewhere, has its own internal flow, shares the parent's data context, and can carry boundary events.

Use it when the logic is specific to this context and won't be reused, when you want to visually group related activities, or when contained exception handling is needed. In Sparx EA, drag a Sub-Process element from the BPMN 2.0 toolbox, double-click to expand, model the internal activities, then collapse for the parent view (right-click → Collapse). The collapsed shape shows the name and a plus sign in the bottom center.

Call Activity: the reuse mechanism

A Call Activity references an existing Global Process or Global Task — a definition that stands independently and can be called from multiple parents. It has its own data scope (input and output mappings define what passes in and out) and renders like an Embedded Sub-Process when collapsed, but with a thick border.

The common mistake is using an Embedded Sub-Process where the logic should be a Call Activity. If you find yourself copying and pasting the same group of activities into multiple diagrams, you've found a Call Activity candidate — redesign it as a Global Process and replace the copies. To build one in Sparx EA: create a Global Process (a BPMN 2.0 Process element with isExecutable = false and isCallableElement = true, or a Sub-Process set to Global), drag a Call Activity onto the parent diagram, and set its Called Element to the Global Process. Double-clicking the Call Activity then navigates to the called diagram.

Event Sub-Process

An Event Sub-Process is triggered by an event, not by sequence flow from the parent. It sits within the parent's scope and activates when its defined event occurs — wherever the parent happens to be at that moment.

  • Interrupting (solid border): when triggered, it interrupts the current activity and takes over; the parent's flow is abandoned.
  • Non-Interrupting (dashed border): when triggered, it runs in parallel with the parent, without interrupting it.

Typical uses: an interrupting cancellation request that stops an order at any point; a non-interrupting status inquiry that responds without disturbing the order; an interrupting timer that escalates an overdue approval. In Sparx EA, draw a Sub-Process inside the parent, set its type to Event Sub-Process, and place a triggering Start Event inside it (Message, Timer, Error, Escalation, Compensation, Conditional, or Signal).

Boundary events: error handling in practice

A Boundary Event is attached to the border of a task or sub-process. When its event occurs during execution, it fires and flow continues from the boundary — interrupting the task or not, depending on the event type.

Error Boundary Event (interrupting). When a task or sub-process throws an error — a technical failure, a business rule violation, an explicitly thrown error — it catches it and routes to an error path; the task is interrupted. Symbol: a lightning bolt in a solid-line circle. Example: a payment task fails on a network error → route to a retry sub-process.

Timer Boundary Event. Fires when a deadline is reached, interrupting (cancel and escalate) or non-interrupting (send a reminder, continue). Message Boundary Event. Fires on a message received during execution. Escalation Boundary Event (non-interrupting). Raised from within a sub-process and caught higher up while the sub-process continues. In Sparx EA, drag a BPMN Intermediate Event onto the border of a task or sub-process — it snaps to the boundary — then set the event type in the properties.

Compensation: modeling rollback and undo

Compensation is BPMN's mechanism for business rollback — undoing completed activities because a later step failed. It has three parts:

  1. Compensation Boundary Event attached to the task that might need undoing — always interrupting and non-canceling, because the task has already completed when compensation triggers.
  2. Compensation Handler Task that performs the undo, connected from the boundary event by an Association (not a Sequence Flow).
  3. Compensation Throw Event placed where rollback should be triggered, firing all relevant handlers.

Example: book hotel → book flight → book car. If the car booking fails, throw Compensation → cancel the flight (handler) → cancel the hotel (handler). In Sparx EA, attach a Compensation Boundary Event to each completed task that might need undoing, draw the handler via an Association, add a Compensation Throw event at the failure point, and connect the failure path to it.

Loop and multi-instance markers

A Loop marker (circular arrow, bottom center) repeats a task until a condition is met, evaluated before each iteration (standard) or after (until) — “retry payment until successful or max retries reached.” A Multi-Instance marker runs a task once per item in a collection, sequentially (three horizontal lines) or in parallel (three vertical lines) — “review each document one by one,” or “notify all team members at once.” Set the loop type in the task's BPMN properties. Disciplined use of these constructs is exactly what separates execution-ready models from decoration, and it's a core part of building real process modeling capability.

Frequently asked questions

When is an Embedded Sub-Process appropriate vs a separate diagram?

Use an Embedded Sub-Process when it is small (three to five activities) and specific to the parent. Use a separate diagram — a Call Activity to a Global Process, or an embedded sub-process with a drill-down — when the logic is complex or reusable. The aim is to keep any one diagram under about fifteen visible elements by pushing detail into sub-processes.

Can a Call Activity have its own boundary events?

Yes. Boundary events can attach to a Call Activity — an Error Boundary Event catches errors thrown within the called process. This lets the calling process handle errors from a reusable Global Process in its own context, without embedding that handling inside the Global Process itself.

How does compensation differ from error handling?

Error handling (Error Boundary Event) deals with a failure during execution: the task is in progress and fails, and flow routes to recovery. Compensation deals with rolling back tasks that already completed successfully, because a later step failed. Error handling moves forward into recovery; compensation undoes completed work. Multi-step processes with partial completion usually need both.

Can Event Sub-Processes be used for audit logging?

Yes. A non-interrupting Event Sub-Process triggered by a Signal (thrown by specific activities) can run audit logging in parallel with the main process. This is cleaner than embedding audit tasks at every step — the logic lives in one place and doesn't clutter the main diagram.

How do I model a task that retries on failure up to a maximum?

Put a Loop marker on the task with a condition that checks the retry count, and add an Error Boundary Event (no loop) for the case where retries are exhausted — that exits the loop and routes to the error path. In Sparx EA, set the loop type on the task and attach the Error Boundary Event for the final failure.

How do sub-processes relate to microservices architecture?

A Call Activity maps naturally to a microservice invocation: the called Global Process represents the logic encapsulated in a service. For executable BPMN on Camunda or Zeebe, the Call Activity configuration carries the service endpoint. Using Call Activities rather than Embedded Sub-Processes aligns the model with a microservices decomposition — each callable process corresponds to a discrete service boundary.

Build process models that are fit for execution.

Talk to a practitioner about BPMN standards, Call Activity library design, and model review for your Sparx EA repository.

Book a call →