The token flow logic for activities depends on whether the multi-instance marker for the activity is set or not and whether the activity is for compensation or not.

Subprocesses and ad-hoc subprocesses (excluding multi-instance and compensation activities)

A token at a subprocess or ad-hoc subprocess changes its state as follows:

stateDiagram-v2
    state feasibleEntry <<choice>>
    state feasibleExit <<choice>>
    state departure <<choice>>
    [*] --> ARRIVED
    note left of ARRIVED
      If an activity does not have any incoming sequence flows,
      the ARRIVED state is skipped
    end note
    ARRIVED --> READY: ready event
    READY --> ENTERED: entry event
    ENTERED --> feasibleEntry
    feasibleEntry --> BUSY: [feasible]
    feasibleEntry --> FAILED: [infeasible]
    BUSY --> COMPLETED
    BUSY --> FAILING: failure
    COMPLETED --> EXITING: exit event
    EXITING --> feasibleExit
    feasibleExit --> departure: [feasible]
    note left of departure
      In case of loop activities, the token may return to ENTERED state
      after receipt of the respective entry event.
    end note
    feasibleExit --> FAILING: [infeasible]
    departure --> DEPARTED: [outgoing sequence flow]
    departure --> DONE: [no outgoing sequence flow]
    DEPARTED --> [*]
    DONE --> [*]
    FAILING --> FAILED
    FAILED --> [*]

ARRIVED

A token in ARRIVED state waits for a ready event indicating that all relevant data has become known. When the event occurs the token state is updated to READY.

READY

A token in READY state waits for an entry event indicating that a decision is made to start with the activity. When the event occurs the token state is updated to ENTERED.

ENTERED

Upon entry, the initial assignment of attributes are conducted in the order of attribute definitions. Then, feasibility of the token status is validated. If any of the restrictions is violated, the token state is updated to FAILED. Otherwise, a token is created at the unique start event of the subprocess or each start node of the ad-hoc subprocess, at the start event of each event subprocess (excluding those having a compensate start event), and at each boundary event (excluding compensate boundary events). These tokens inherit the status attributes of the (ad-hoc) subprocess token. Furthermore, the token state is updated to BUSY.

Note: Subprocesses must have a unique blank start event.

Note: Ad-hoc subprocesses must not contain any start event and any flow node without incoming sequence flows must be a an activity.

Note: Event-subprocesses must have a unique typed start event.

Attention: A failure occurring at this stage can not yet be caught by an event subprocess with an error start event.

BUSY

A token remains in BUSY state until the process

is terminated due to an uncaught failure,
is interrupted by an interrupting boundary event, or
the last active token within the scope has completed without failure.

While the token is in BUSY state, the token status may be updated due to an escalation raised downstream by an escalation event. If the token resides at a (ad-hoc) subprocess which is the performer of a sequential ad-hoc subprocess, the token status is also updated whenever a token exits a child activity of the sequential ad-hoc subprocess.

When an uncaught failure is raised within the scope of the (ad-hoc) subprocess, the status of the (ad-hoc) subprocess token is set to the status of the token raising the failure. All tokens within the scope of the process (excluding those created for compensation) are disposed before the state of the process token is updated to FAILING.

Note: A failure occurring at this stage may be caught by an event subprocess with an error start event.

When all tokens within the scope of the (ad-hoc) subprocess have reached DONE state and no event subprocess is running, the status of the (ad-hoc) subprocess token is updated with the merged status of all these tokens within the scope. All child tokens are disposed (including those at start events of event subprocesses) before the state of the (ad-hoc) subprocess token is updated to COMPLETED.

An (ad-hoc) subprocess also completes if an event subprocess with a start event that is interrupting completes successfully. In such a case, the token status of the (ad-hoc) subprocess is analogously updated with the merged status of all tokens in DONE state within the scope of the interrupting event subprocess. All of these tokens are disposed before the state of the (ad-hoc) subprocess token is updated to COMPLETED.

COMPLETED

When a token at the (ad-hoc) subprocess with an event subprocess with a compensate start event reaches COMPLETED state, a token is created at this start event. If the (ad-hoc) subprocess has a compensate boundary event, a token is created at this boundary event.

A token in COMPLETED state waits for an exit event indicating that a decision is made to leave the activity. When the event occurs the token state is updated to EXITING.

EXITING

Feasibility of the token status is validated. If any of the restrictions is violated, the token state is updated to FAILING.

Note: The failure occurring at this stage can no longer be caught by an event subprocess with an error start event, but an event subprocess with a compensate start event can be triggered.

Otherwise, the (ad-hoc) subprocess has been executed successfully and all tokens at boundary events (except compensate boundary events) of the (ad-hoc) subprocess are withdrawn.

If the (ad-hoc) subprocess has an outgoing sequence flow, the token state is updated to DEPARTED. Otherwise, the token state is updated to DONE. In case of loop activities, the token may advance to ENTERED state after the respective entry decision has been made for the next loop of the activity.

DEPARTED

When the (ad-hoc) subprocess token reaches DEPARTED state, the token moves to the next node.

DONE

When the (ad-hoc) subprocess token reaches DONE state, the token remains at the node until all other tokens in the parent scope have reached DONE state or a failure occurred.

Note: When all tokens in the parent scope have reached DONE state, the state of the parent token is changed to COMPLETED state.

FAILING

When the process token reaches FAILING state, the status of the process token is updated using the values of the token causing the failure, all tokens within the scope of the process are withdrawn, and the state of the process token is updated to FAILED after all relevant activities within the scope of the process have been compensated.

FAILED

Upon failure, the state of a token at an error boundary event is changed to COMPLETED. If no such error boundary event exists, the error is bubbled up to its parent scope.