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.

A process architect's job is to decide how a process is packaged and how it behaves when something goes wrong: what is reused, what is local, what is retried and what is rolled back. Building the sub-processes, attaching boundary events and wiring compensation handlers is mechanical work. In AI-augmented work the architect states the packaging and failure rules, and AI builds the structure in the model and checks that each reusable process is called rather than copied. The skill is knowing these constructs well enough to specify the behavior and to review what comes back. The reference below is that knowledge.

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.

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. 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, 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-line start event): when triggered, it interrupts the current activity and takes over; the parent's flow is abandoned.
• Non-Interrupting (dashed-line start event): 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. It becomes active only once that task has completed.
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), for example “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), for example “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 what makes a model ready for execution, and it is a core part of process modeling capability.

Frequently asked questions