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.

Each state has a name and an associated integer value that is used to identify the state programmatically. For each non-end state, a set of events or actions cause the activity to go into another state.

Waiting (40)

An activity is in the Waiting state because the precondition evaluated to false. When one of the following events occurs, the state of the activity will change:

• When the precondition evaluates to true:
  • If it is an automatic activity, it changes to the Launching state.
  • If it is a manual activity, it changes to the Ready state.
• If the activity is optional, and the enclosing scope ends, the activity changes to the Not used state.

Launching (70)

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 (10)

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 activity is optional, and the enclosing scope ends, the activity changes to the Not used state.

Working (20)

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 (30)

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

Tip: In Process Portal, the activity filter category Completed indicates how many activities are in any of the end states: Completed, Skipped, or Not used. If you click Completed, the displayed list of activities is filtered to show the ones that are in any of the end states, not just the ones that are in the Completed state. Activities in the skipped state are known as canceled activities in Process Portal.

Failed (60)

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 (80)

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

Skipped (90)

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 excluding, or skipping, the task that implements an activity in the instance. In Process Portal, activities in the Skipped state are shown as canceled activities in the list of completed activities.