The state of a token at a typed start event is immediately advanced from ENTERED to BUSY and awaits the trigger. If the token is at a message start event, the message content is used to update the status of the token. Thereafter, the operators of the respective event-subprocess are applied.

After the start event is triggered, the state is advanced COMPLETED. If the respective event-subprocesses is interrupting, all other tokens within the scope of the event-subrocess are withdrawn. Otherwise, a new token is created allowing the event-subprocess to be triggered again.

After completion, the entry scope restrictions of the event-subprocess are checked. If the restrictions are violated, the state is changed to FAILED. Otherwise, the operators of the event-subprocess are applied and the state is changed to EXITING. Then, the full scope restrictions of the context are validated and either a failure is raised or the token state is changed to DEPARTED or DONE.

stateDiagram-v2
    state feasibleEntry <<choice>>
    state feasibleExit <<choice>>
    state departure <<choice>>
    [*] --> ENTERED
    ENTERED --> BUSY
    BUSY --> COMPLETED: trigger
    COMPLETED --> feasibleEntry
    feasibleEntry --> EXITING: [feasible]
    feasibleEntry --> FAILED: [infeasible]
    EXITING --> feasibleExit
    feasibleExit --> departure: [feasible]
    feasibleExit --> FAILED: [infeasible]
    departure --> DEPARTED: [outgoing sequence flow]
    departure --> DONE: [no outgoing sequence flow]
    DEPARTED --> [*]
    DONE --> [*]
    FAILED --> [*]

Attention: Typed start events are only supported for event-subprocesses.

Note: Operators for event-subprocesses must be instantaneous, i.e. they must not change the timestamp.