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.

Tasks (excluding multi-instance and compensation activities)

A token at a task 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: completion event
    BUSY --> FAILED: 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 --> FAILED: [infeasible]
    departure --> DEPARTED: [outgoing sequence flow]
    departure --> DONE: [no outgoing sequence flow]
    DEPARTED --> [*]
    DONE --> [*]
    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, a token is created at each boundary event (excluding compensate boundary events). These tokens inherit the status attributes of the task token. Then, feasibility of the token status is validated. If any of the restrictions is violated, the token state is updated to FAILED. Otherwise, the token state is updated to BUSY.

BUSY

For a task which is not a send task, receive task or decision task, the operators are applied to update the status of the token.

If the token resides at a send task, the operators are applied and a message is created. The token waits for a message delivery event at any of the recipients before the state is changed to COMPLETED state.

A token at a receive task waits for a message delivery. When the message is delivered, the message content is used to update the status of the token. Thereafter, the operators are applied and the token state is updated to COMPLETED.

A token at a decision task waits for a choice to be made. When the choice is made, the status of the token is updated accordingly. Thereafter, the operators are applied and the token state is updated to COMPLETED.

If any other task increments the timestamp, the token waits for a completion event before the state is changed to COMPLETED state. Otherwise, the token state is directly updated to COMPLETED.

Attention: Operators for send tasks, receive tasks, and decision tasks must be instantaneous, i.e., they must not change the timestamp. For send tasks operatores are applied before the message is sent, for receive tasks they are applied after the message is received, and for decision tasks they are applied after the choices have been made, respectively.

Note: The timestamp of a task in BUSY state may be in the future, representing an expected completion time.

COMPLETED

When a token at a task with a compensate boundary event reaches COMPLETED state, 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 FAILED.

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

If the task 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 token reaches DEPARTED state, the token moves to the next node.

DONE

When the 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.

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.