Runtime states for activities in process applications

At run time, different events cause activities to transition between various states. And the state that an activity is in determines which actions can be performed.

When an activity's parent process is started, if the activity has a precondition, the precondition is evaluated. Depending on the type of the activity and any preconditions, the activity is put into one of three initial states:

• If an automatic activity has no precondition or if it has a precondition that evaluated to true, the activity is put into the WORKING state.
• If a manual activity has no precondition or if it has a precondition that evaluated to true, the activity is put into the READY state.
• For both automatic and manual activities, if the activity has a precondition that evaluated to false, the activity is put into the WAITING state.

For each non-end state, a set of events or actions cause the activity to go into another state.

WAITING

An activity is in the WAITING state because the precondition evaluated to false. In Process Portal and Process Inspector, manual activities with the WAITING state are in the Ready category while automatic activities with the WAITING state are in the In progress category. When one of the following events occurs, the state of the activity changes:

• When the precondition evaluates to true:
  • If it is an automatic activity, the activity changes to the LAUNCHING state.
  • If it is a manual activity, the activity changes to the READY state.
• If the user clicks Disable or the corresponding REST API is invoked, the activity changes to the DISABLED state.
• If the activity is optional and the enclosing scope ends, the activity changes to the NOT USED state.

LAUNCHING

The LAUNCHING state is transitory for automatic activities. It indicates that the activity is starting. When the activity is successfully started, it automatically changes to the WORKING state.

READY

When a manual activity is in the READY state, it waits until one of following events occurs:

• If the user clicks Start or the corresponding REST API is invoked, the activity changes to the WORKING state.
• If the user clicks Disable or the corresponding REST API is invoked, the activity changes to the DISABLED state.
• If the activity is optional and the enclosing scope ends, the activity changes to the NOT USED state.

WORKING

An activity stays in the WORKING state until one of the following events occurs:

• If the activity completes successfully, it changes to the COMPLETED state.
• If the activity completes unsuccessfully, it changes to the FAILED state.

COMPLETED

The COMPLETED state is an end state for activities that completed successfully.

FAILED

If an error occurs during the completion of an activity, it is put into the FAILED state. An activity stays in the FAILED state until the administrator completes one of the following actions in the Process Admin console:

• The administrator repairs the activity and restarts it. The activity is put into the WORKING state.
• The administrator determines that the activity cannot be repaired puts it into the SKIPPED state. The processing of the instance continues without the activity.

NOT USED

The NOT USED state is an end state for optional activities that are no longer available because the enclosing scope for the activity closed.

DISABLED

• If the user clicks Enable or the corresponding REST API is invoked, the activity returns to the state that the activity was in when it was disabled: WAITING or READY.
  Remember: If the activity was in the WAITING state when it was disabled and the precondition now evaluates to true, the activity changes to the READY state.
• If the activity is optional and the enclosing scope ends, the activity changes to the NOT USED state.

SKIPPED

The SKIPPED state is an end state for activities. This state occurs when an administrator repairs a failed process instance in the Process Admin console by canceling the activity in the instance.