not_started

This is the starting state of all task instances after process creation.

The state is left automatically after the workflow server has entered the task.

waiting

This state is entered automatically, after the task is reached by the workflow server.

It is also entered from the activated state if instance context changes have been made. So the guards are recalculated.

The state is left automatically when the task is ready for activation, that is if the following conditions have been fulfilled:

activated

This state is entered automatically, after the waiting state has been left.

Assigning a task

If this state has been entered, you can nominate a user or group for this task via Task.assignTo(). So only these users will see the task in their task list (if they have the appropriate rights). This operation will not change the state of the task.

Rejecting a task

A user can also reject the task via Task.reject(), so it will not be offered to him anymore. If all appropriate users have rejected the task, it will be offered again to all these users (this is the default performers policy).

Canceling a task

The state activated is also entered if a task was accepted by a user and then canceled by this user via Task.cancel(). All changes made so far by the user are saved, but the task is offered again to all appropriate users like before it was accepted.

A user task must be accepted by the user in order to leave the state 'activated' via Task.accept(). Then preconditions and entry actions are performed. After successfully running the actions, the task is performed by the user and no more available to other users.

Another way to leave the state is to skip the task via Task.skip(), switching to the state 'skipping'.

A fallback to waiting is possible.

suspended

This state can only be entered via Process.suspend() which suspends the workflow. All task are withdrawn from the task list (GUI specific).

This state can be left via Task.resume(). The workflow will restart at the same task where it was suspended.

running

If an automated task has been activated it automatically leaves the state 'activated' and changes to 'running'.

A user task must be accepted by the user via Task.accept() in order to enter the state 'running'. The task is then performed by the user and is no more available to other users.

An automated task leaves the state 'running' and enters one of the states 'completed' (via Task.complete()) and 'aborted' depending on the success of the actions and preconditions and Postconditions performed.

A user task can leave the state 'running' and enter one of the states 'waiting', 'completed' (via 'completing') and 'aborted'.

'Activated' is reached, when the user cancels the task via Task.cancel(). All changes made so far by the user are saved, but the task is offered again to all appropriate users.

'Completed' is reached, when the task is completed via Task.complete() and the exit actions execute successfully and the post-conditions evaluate to "true".

'Aborted' is reached, when one of the exit actions and postconditions fails.

skipping

Intermediate state.

Intermediate state.

skipped

This state is entered if the task has been skipped by a user via Task.skip(). The process continues with the following task.

This state can only be left, when the flow of operation returns to the task. That is, there is a loop in the workflow definition which returns to the task.

completing

Intermediate state.

Intermediate state.

completed

An automated task enters this state when all actions have been successfully performed and the preconditions and postconditions have been evaluated to "true".

A user task enters this state when the user completes the task, the exit actions have been successfully executed and the post-conditions evaluated to "true".

This state can only be left, when the flow of operation returns to the task. That is, when there is a loop in the workflow definition, which returns to the task.

aborted

This state is entered if the process is aborted via Process.abort().

Final state.