Boundary Event

What a Boundary Event Is

A BPMN 2.0 boundary event is an intermediate catch event that is attached to the border of an activity. It listens for a trigger (a deadline, a message, an error, a signal, a change in data) while the activity is running, and when the trigger happens it opens a path out of that activity.

• It always sits on the border of a task, sub-process, transaction, or call activity. It cannot be attached to an event or a gateway, and it cannot float free in the flow.
• It has outgoing sequence flows but no incoming sequence flow: the activity it is attached to is the only entry point.
• It only listens while its activity is active. If the activity finishes first, the boundary event never fires. Compensation is the exception: it is armed after its activity completed.
• When the trigger fires, a token leaves through the boundary event’s outgoing flow. An interrupting event replaces the activity’s token; a non-interrupting event adds one next to it.
• In the notation it is drawn as a double circle on the activity’s edge, with the trigger symbol inside.

ProcessMind supports boundary events for every type listed on this page. Drag one from the Boundary Event or Boundary Non-Int. group in the BPMN Elements palette onto the border of an activity to attach it. Dragging an existing intermediate catch event onto an activity border attaches it too, and dragging it off again detaches it. Both the attachment and the interrupting setting survive a BPMN export and re-import.

Interrupting vs Non-Interrupting

Boundary events come in two forms, and the form decides what happens to the activity when the trigger arrives.

	Interrupting	Non-interrupting
Drawn as	A solid double ring	A dashed double ring
Effect on the activity	Immediately cancelled; the work in it is abandoned	Keeps running; nothing is cancelled
Paths after the trigger	Only the boundary path; the activity’s normal outgoing flow is not taken	Both: the normal path continues and the boundary path runs in parallel
How often it can fire	Once; the activity is gone after the trigger	More than once while the activity stays active, for example on every cycle of a repeating timer
BPMN attribute	cancelActivity="true"	cancelActivity="false"

An interrupting boundary event replaces the normal continuation of the activity. A non-interrupting boundary event branches off from it.

Use interrupting when the trigger makes the activity pointless or unsafe to finish: a missed deadline, a failure, a withdrawal. Use non-interrupting when the trigger calls for extra work alongside the activity, or for a reminder or notification that should not throw away the work in progress.

Both forms only make sense while the activity is active. An interrupting event that fires cancels the activity, so any other boundary events on that activity are disarmed at the same time. A non-interrupting event leaves the activity and its other boundary events in place.

One activity, several boundary events. A single activity can carry several boundary events. A common mix on an approval task is:

• An interrupting timer after two business days: escalate and stop the task.
• A non-interrupting timer every four hours: send a reminder and let the task continue.
• An interrupting error on the sub-process that does the actual check: handle a technical failure.

Types of Boundary Events

ProcessMind supports the types below. The interrupting group is larger, because some triggers only make sense when they stop the activity.

Interrupting Boundary Events

Type	What it means	Typical example
Message	Waits for a specific message addressed to this activity.	“Wait for supplier quote” is interrupted by the message “quote withdrawn” and continues to “Source alternative supplier”.
Timer	A deadline: a duration, a date, or a cycle calculated from the moment the activity started.	“Approve expense” has a two-day timer; if it has not finished, the case moves to “Escalate to finance manager”.
Error	Catches an error thrown inside the activity and stops it. Error boundary events are always interrupting.	“Run credit check” sub-process throws “check failed”; the boundary path goes to “Request manual underwriting”.
Escalation	Stops the activity because a higher level needs to take over.	“Resolve incident” is escalated after the first-response target is missed and moves to “Incident commander takes over”.
Cancel	Catches the cancel end event of a transaction sub-process. Only valid on a transaction.	“Book travel” transaction is cancelled by the customer; the boundary path goes to “Refund payment and release reservations”.
Compensation (special case)	Runs the compensation handler for an activity that already completed, to undo its effect. It does not cancel work in progress.	“Charge deposit” is compensated by “Refund deposit” when the order is cancelled later in the process.
Conditional	Fires when a business condition becomes true while the activity is running.	“Reserve stock” is interrupted when availableStock < orderedQuantity; the case moves to “Backorder and notify customer”.
Signal	Catches a broadcast signal. A signal is not addressed to one activity; every matching listener can react.	“Collect missing documents” is interrupted by the company-wide signal “case withdrawn” and the case is closed.
Multiple	Fires when any one of several triggers occurs.	“Wait for customer reply” catches either the message “reply received” or a ten-day timer; whichever comes first cancels the wait.
Parallel Multiple	Fires only when all of its triggers have occurred.	“Gather release approvals” waits for both the legal approval message and the security approval message before it proceeds.

A few rules of thumb for this group:

• Error belongs on a sub-process, call activity, or transaction, so on the activity that can actually throw the error. On a plain task there is nothing inside to fail.
• Cancel belongs on a transaction sub-process. Elsewhere it has nothing to catch.
• Compensation is the special case. It is armed after its activity completed and is triggered by a compensation throw elsewhere in the process. It models “undo the step that already happened”, not “stop the step that is running”.
• Multiple is a race between triggers. Parallel Multiple is a gate that waits for all of them.

Non-Interrupting Boundary Events

Type	What it means	Typical example
Message	A message arrives while the activity continues; the message starts a side path.	“Draft proposal” keeps running when the message “reviewer comment received” starts “Log review comment”.
Timer	A reminder or periodic check; the activity is not stopped.	“Handle support ticket” has an eight-hour repeating timer that starts “Send status update” while handling continues.
Escalation	Raises an escalation alongside the activity without ending it.	“Resolve complaint” keeps running while the escalation “customer is strategic” starts “Notify account director”.
Conditional	A condition triggers a side path while the activity continues.	“Process loan application” keeps running when riskScore > 70 starts “Flag for audit review”.
Signal	A broadcast starts a side path for every listener; the activity continues.	“Run nightly batch” keeps running when the signal “market closed” starts “Snapshot interim totals”.
Multiple	Any one of several triggers starts a side path; the activity continues.	“Negotiate contract” stays open; either a counterparty message or a three-day timer starts “Send nudge”.
Parallel Multiple	All triggers together start a side path; the activity continues.	“Wait for all checks” stays active until both the message and the signal have arrived, then starts “Record readiness”.

Non-interrupting boundary events are the tool for reminders, notifications, observation, and parallel escalation. They do not change the main flow; they add a branch next to it.

Event Types That Are Not Boundary Events

Some event types look as if they could be boundary events, but they are not:

• Link events connect parts of a flow. They are intermediate catch or throw events in the sequence, not attachments.
• Terminate ends a whole process instance and exists only as an end event.
• None is not a trigger, so a boundary event can never be “None”: every boundary event needs something to catch.

Adding a Boundary Event in ProcessMind

1. Open the BPMN Elements palette.
2. Pick a type from the Boundary Event group for an interrupting event, or from Boundary Non-Int. for a non-interrupting one.
3. Drag it onto the border of a task, sub-process, transaction, or call activity.
4. Drop it. The event snaps to the nearest edge and the activity becomes its host.
5. Draw the sequence flow from the boundary event to the first step of the exception or side path.

Tips for working with them:

• Dropping an intermediate event on an activity border attaches it. Dropping the same event in open canvas creates a normal intermediate catch event. Drag it onto a border later to attach it, or drag it off to detach it.
• A boundary event moves, hides, and is deleted together with its host activity. It is never placed independently of an activity.
• The non-interrupting version is a separate palette entry, not a checkbox. Pick it before you drag if the activity must keep running.
• On export, the attachment is written as attachedToRef and the interrupting setting as cancelActivity. Both are restored when the file is imported again.

Common Mistakes

• A boundary event without an outgoing flow. It catches the trigger and then has nowhere to go, so the exception path is a dead end.
• A non-interrupting timer where a hard stop is needed. The activity keeps running, so the deadline does not end the work. Use the interrupting version for a deadline.
• An error boundary on a plain task. Attach it to the sub-process or call activity that contains the failing step.
• Expecting a boundary event to fire after the activity finished. It cannot, except for compensation, which is armed after completion.
• Using Cancel outside a transaction. The cancel boundary event is defined for transaction sub-processes only.
• Two interrupting events on one activity and expecting both paths. The first trigger wins; the activity and its other boundary events are cancelled with it.

All Events with Their Corresponding Symbols

Generate a Custom BPMN Model

Related topics

• Events: all event types.
• Intermediate Event: events in the middle of a flow.
• Activities: the tasks and sub-processes a boundary event can attach to.
• Supported BPMN Elements: what ProcessMind imports and exports.
• BPMN 2.0: A Practical Guide: the notation with worked examples.