Boundary events

A boundary event sits on the edge of a task and catches something that happens while the task runs, such as an error or a deadline. Write it as an indented line under the task:

process Card payment

start Checkout completed
service Charge card
  on:error Card declined -> Ask for another card
  on~timer(PT10M) Charge taking long -> Notify support
end Payment taken

user Ask for another card
end Payment failed

send Notify support
end Support notified

• on: makes an interrupting event: the task stops and the flow leaves through the event.
• on~ makes a non-interrupting event: the task keeps running and the event starts a path alongside it.
• The event type comes right after on: or on~, and it's required. A space between them is fine: on: error reads the same as on:error. Timers take their argument the same way as other events: on~timer(PT10M).
• The name and the -> Target are optional, but a boundary event with nowhere to go is a dead end the checks will flag.

Boundary events don't end the chain. In the example, Charge card still connects to Payment taken on the next line.

Attach them to tasks, sub-processes and call activities only: the checks report an error for a boundary event on a gateway or another event. A boundary event can't take an #id, and an arrow by name never points to one.

For more, see Deadlines and reminders and Errors and exceptions.