Direct Answer
BPMN provides three sub-process mechanisms. An Embedded Sub-Process is a sub-process contained inside its parent process: it is not reusable. A Call Activity references a separate Global Process definition that can be called from multiple parent processes: it is the reuse mechanism. An Event Sub-Process is triggered by an event within its parent process scope, not by the normal sequence flow: it handles interrupting or non-interrupting exception scenarios. Error handling in BPMN uses Boundary Events attached to tasks or sub-processes: an Error Boundary Event interrupts the task/sub-process and routes to an error-handling path. Compensation uses a Compensation Boundary Event and Compensation Handler to model rollback or undo logic. The most common mistake is using an Embedded Sub-Process when the logic is genuinely reusable: the right call is a Call Activity pointing to a Global Process. In Sparx EA, Call Activities link to separate process diagrams via the Called Element property.
Embedded Sub-Process
An Embedded Sub-Process is a process within a process. It groups a set of activities into a named unit that can be shown as an expanded view (showing all internal activities) or collapsed (showing just the boundary with a small plus icon indicating internal content).
Characteristics:
- Contained within the parent process: not callable from elsewhere
- Has its own internal sequence flow, gateways, events, and activities
- Shares data context with its parent process (no separate data scope boundary)
- Can have Boundary Events attached to its outer boundary
When to use:
- The logic is specific to this process context and will not be reused elsewhere
- You want to visually group a set of related activities for clarity
- The sub-process has exception handling (boundary events) that needs to be contained
In Sparx EA:
- Drag a Sub-Process element from the BPMN 2.0 toolbox onto the diagram
- Double-click to expand the sub-process
- Model the internal activities within the expanded view
- Collapse the sub-process for the parent-level diagram view (right-click → Collapse)
The collapsed sub-process shows the sub-process name and a small plus sign (+) in the bottom-center of the shape.
Call Activity: The Reuse Mechanism
A Call Activity references an existing Global Process or Global Task: a process definition that stands independently and can be called from multiple parent processes.
Characteristics:
- References an external process definition: the Global Process
- Reusable: multiple parent processes can call the same Global Process
- Has its own data scope: input and output mappings define what data passes in and out
- Rendered identically to an Embedded Sub-Process when collapsed, but with a thick border
When to use:
- The logic is (or should be) reused across multiple processes
- Standard operating procedures that are invoked from different entry points
- Common sub-processes: “Customer Identity Verification”, “Credit Approval”, “Invoice Generation”
The common mistake: using Embedded Sub-Process when the logic should be a Call Activity. If you find yourself copying and pasting the same group of activities into multiple process diagrams, you have identified a Call Activity candidate. Redesign as a Global Process and replace the copies with Call Activities.
In Sparx EA:
- Create a Global Process: in the Project Browser, create a new BPMN 2.0 Process element marked as
isExecutable = falseandisCallableElement = true(or use the Sub-Process element type set to Global) - On the parent process diagram, drag a Call Activity element from the BPMN 2.0 toolbox
- In the Call Activity properties, set the Called Element to point to the Global Process
- In Sparx EA, double-clicking the Call Activity navigates to the called process diagram
The called process diagram is a separate diagram in the repository: maintainable independently, referenceable from any number of parent processes.
Event Sub-Process
An Event Sub-Process is triggered by an event, not by sequence flow from the parent process. It sits within its parent process scope and is activated when a defined event occurs: regardless of where the parent process is at that moment.
Types:
- Interrupting Event Sub-Process: when triggered, it interrupts the current activity in the parent process and takes over. The parent’s current flow is abandoned. Indicated by a solid line border.
- Non-Interrupting Event Sub-Process: when triggered, it runs in parallel with the parent process, without interrupting it. Indicated by a dashed line border.
Common use cases:
- Interrupting: a cancellation request received at any point in an order process that stops the order and runs the cancellation procedure
- Non-Interrupting: a status inquiry received during an order process that triggers a status check and response without interrupting the order itself
- Interrupting: a timer that fires if an approval is not received within 48 hours, escalating to a supervisor
In Sparx EA:
- Draw a Sub-Process element within the parent process diagram
- Set its type to Event Sub-Process
- Place a Start Event inside the Event Sub-Process: this start event must be a triggering event type (Message, Timer, Error, Escalation, Compensation, Conditional, Signal)
- Model the internal handling process
Boundary Events: Error Handling in Practice
A Boundary Event is attached to the boundary of a task or sub-process. When the defined event occurs during execution of that task or sub-process, the boundary event fires and sequence flow continues from the boundary event: interrupting (or not) the task.
Error Boundary Event (Interrupting). When a task or sub-process throws an error: a technical failure, a business rule violation, or an explicitly thrown error: the Error Boundary Event catches it and routes to an error-handling path. The task is interrupted and does not complete normally.
Symbol: lightning bolt icon inside the event circle, on the task/sub-process border. Solid line circle = interrupting.
Use case: a payment processing task fails due to a network error → Error Boundary Event → route to payment retry sub-process or notification task.
Timer Boundary Event. When a deadline is reached during task execution, the timer fires. Can be interrupting (cancel the task and proceed to escalation) or non-interrupting (send a reminder but continue the task).
Symbol: clock icon inside the event circle.
Use case (interrupting): an approval task must complete within 24 hours → Timer Boundary Event (24 hours) → escalate to supervisor. Use case (non-interrupting): send a reminder after 12 hours → Timer Boundary Event (12 hours, non-interrupting) → send reminder task → continue waiting for approval.
Message Boundary Event. A message received during task execution triggers the boundary event.
Escalation Boundary Event (Non-Interrupting). An escalation is raised from within a sub-process and caught at a higher level. Typically non-interrupting: the sub-process continues while the escalation is handled by the parent.
Compensation Boundary Event. See the Compensation section below.
In Sparx EA: Attach boundary events by dragging a BPMN Intermediate Event element onto the border of a task or sub-process. Sparx EA snaps the event to the boundary. Select the event type in the element properties.
Compensation: Modeling Rollback and Undo
Compensation is BPMN’s mechanism for business rollback. When a process needs to undo completed activities (because a later step failed), compensation handlers define what the undo logic looks like for each activity.
Components:
- Compensation Boundary Event: attached to the task that might need to be undone. It is always interrupting and non-canceling (the task has already completed when compensation is triggered).
- Compensation Handler Task: the task that performs the undo: connected from the Compensation Boundary Event via an Association (not a Sequence Flow).
- Compensation Throw Event: an Intermediate Throw Event of type Compensation, placed where the rollback should be triggered. It triggers all relevant compensation handlers.
Example: book hotel → book flight → book car rental. If car rental fails, throw Compensation → undo flight booking (Compensation Handler: cancel flight) → undo hotel booking (Compensation Handler: cancel hotel).
In Sparx EA:
- Add a Compensation Boundary Event to each completed task that might need undoing
- Draw a Compensation Handler Task (use an Association, not Sequence Flow)
- At the failure point, add a Compensation Throw Intermediate Event
- Connect the failure path (from Error Boundary Event or gateway) to the Compensation Throw Event
Loop and Multi-Instance Markers
Loop Marker. A task with a Loop marker repeats until a condition is met. The loop condition is evaluated before (standard loop) or after (until loop) each iteration.
Symbol: circular arrow icon in the bottom-center of the task.
Use case: “Retry payment until successful or maximum retries reached.”
Multi-Instance Marker. A task with a Multi-Instance marker executes once for each item in a collection: either sequentially (one at a time) or in parallel (all at once).
Symbol: three horizontal lines (sequential) or three vertical lines (parallel) in the bottom-center of the task.
Use case (sequential): “Review each document in the submission package one by one.” Use case (parallel): “Send notification to all team members simultaneously.”
In Sparx EA, set the loop type in the task’s BPMN properties panel.
Frequently Asked Questions
Q: When is an Embedded Sub-Process appropriate vs a separate diagram? A: Use an Embedded Sub-Process (shown as a collapsed element in the parent diagram, expanded in the same diagram) when the sub-process is small (three to five activities) and specific to the parent. Use a separate diagram (Call Activity pointing to a Global Process, or an Embedded Sub-Process with a drill-down diagram) when the sub-process is complex or reusable. The key is avoiding diagrams with more than about fifteen visible elements: use sub-processes to manage visual complexity.
Q: Can a Call Activity have its own boundary events? A: Yes. Boundary events can be attached to a Call Activity: error boundary events catch errors thrown within the called process. This is the mechanism for centrally handling errors from a reusable global process without embedding error handling in the global process itself (which would prevent the calling process from handling errors in its own context).
Q: How does compensation differ from error handling? A: Error handling (Error Boundary Event) deals with failures during execution: the task is currently in progress and fails. Compensation deals with rollback of completed tasks: the task has already finished successfully, but a later failure requires it to be undone. Error handling routes to recovery logic in the forward path. Compensation rolls back already-completed work. Both are needed in processes with multiple steps where partial completion must be handled.
Q: Can Event Sub-Processes be used for audit logging? A: Yes. A non-interrupting Event Sub-Process triggered by a Signal (thrown by specific activities in the main process) can run audit logging logic in parallel with the main process. This is cleaner than embedding audit tasks in every process step: the logging logic is in one place and does not clutter the main process diagram.
Q: How do we model an activity that must retry on failure up to a maximum number of times? A: Use a Loop marker on the task, with the loop condition checking whether the maximum retry count has been reached. Combine with an Error Boundary Event (with no loop) for the case where the maximum retries are exhausted: this exits the loop and routes to the error-handling path. In Sparx EA, set the loop type on the task and add an Error Boundary Event to handle the final failure.
Q: What is the relationship between BPMN sub-processes and microservices architecture? A: A Call Activity maps naturally to a microservice invocation. The Global Process called by the Call Activity can represent the business logic encapsulated in a specific microservice. When process models are designed as executable BPMN (run on Camunda or Zeebe), the Call Activity configuration includes the microservice endpoint. Using Call Activities rather than Embedded Sub-Processes makes the BPMN model align with a microservices decomposition: each callable global process corresponds to a discrete service boundary.
Next Step
BPMN sub-process design: knowing when to use embedded vs call activity, how to structure error handling, and how to model compensation: is foundational to process models that are fit for execution, not just communication. The Amplify engagement includes BPMN process modeling standards, Call Activity library design, and the review process to ensure your process models are architecturally sound.
