States and transitions of the default task workflow

You can execute the transitions of the default task workflow in the following states of the task object (status), depending on whether you are involved as the creator, person responsible for implementation or reviewer:

• Create task

• Task waiting for processing

• Task returned to creator

• Task waiting for testing

• Task tested

• Task delegated

Create task

By clicking on Create task in My tasks to start the task workflow. In the workflow screen, you determine the properties of the task, such as the due date or the organizational reference and who is responsible for implementation. Newly created tasks have the status Task waiting for processing. The users to whom you have assigned implementation responsibility are informed in the Portal header and by email that they have been assigned a new task.

Task waiting for processing

If the task has the status Task waiting for processing, the person responsible for implementation and the creator can decide how to proceed with the task. You have several options here:

• Complete task: Those responsible for implementation can implement the task immediately. The task is assigned the status Task implemented. The creator is informed by e-mail that the task has been completed.

• Cancel task: Those responsible for implementation can cancel the task. The workflow is no longer continued. The task is assigned the status Task canceled. The creator is informed by e-mail that the task has been canceled.

• Forward for testing: Those responsible for implementation can forward the task to one or more testers. The task is assigned the status Task waiting for testing. The assessors are informed via the Portal header and by e-mail that they have been assigned a new task.

  Note: You can assign the test of a general task to employees, roles or user groups.

  See also: How to proceed with a task during the test is described in detail below.

• Delegate task: Those responsible for implementation and the creator can delegate responsibility for implementation to an employee, a role or a user group. The task is assigned the status Task delegated. The new user responsible for implementation is informed of the new task by e-mail and via the Portal header. The creator also receives a notification via the Portal header.

  See also: How delegated tasks can be handled is described in detail below.

• Return task: Those responsible for implementation can return the task to the creator. The task is assigned the status Task returned to creator. The creator is informed via the Portal header and by e-mail that he/she has been assigned a new task.

  See also: How the creator can proceed if the task has been returned is described in detail below.

• Assign task to me: If the implementation responsibility has been assigned to a user group or a role, a user who is responsible for the task implementation can assign the task to him/herself. This user has then withdrawn the execution authorization from all other assigned authorized users. The status of the task remains Task waiting for processing.

• Delete task: The creator can delete the task again. Deleted tasks have the status Task deleted.

Task returned to creator

If the person responsible for implementation returns the task to the creator, it has the status Task returned to creator. The creator has the following options here:

• Complete task: The creator can complete the task him/herself. The task is assigned the status Task implemented. The creator is informed by e-mail that the task has been completed.

• Delegate task: The creator can reassign the implementation of the task to a user, a role or a user group. The task is assigned the status Task delegated. The new user responsible for implementation is informed of the new task by e-mail and via the Portal header.

  See also: How delegated tasks can be handled is described in detail below.

• Cancel task: The creator can cancel the task. The task is assigned the status Task canceled.

Task waiting for testing

Once a person responsible for implementation has forwarded the task for review, the task is assigned the status Task waiting for testing. The employees, roles or user groups assigned to the test have the following options here:

• Complete check: Once the check has been completed, the task is assigned the status Task tested. From there, the task implementation can decide how to proceed with the task. The task implementation and the creator are informed by e-mail that the test has been completed. In addition, those responsible for implementation are informed of the new task via the Portal header.

  See also: How to proceed with a successfully tested task is described in detail below, as it is relevant for several statuses.

• Decline task: If the tester declines the task, the workflow is no longer continued. The task is assigned the status Task declined. The creator is informed by e-mail that the task has been declined.

• Assign test to me: If the test has been assigned to a user group or a role, a user who is authorized to perform the test can assign the test to him/herself. This user has then withdrawn the execution authorization from all other assigned authorized users. The status of the task remains Task waiting for review.

• Delegate task: Testers can return the task to the person responsible for implementation or change the person responsible for implementation. The task is assigned the status Task delegated. The new user responsible for implementation is informed of the new task by e-mail and via the Portal header. The creator also receives a notification via the Portal header.

  See also: How delegated tasks can be handled is described in detail below.

Task tested

If a task has been tested, the task is assigned the status Task tested. Those responsible for implementation have the following options here:

• Assign task to me: If the implementation responsibility has been assigned to a user group or a role, a user who is responsible for the task implementation can assign the task to him/herself. This user has then withdrawn the execution authorization from all other assigned authorized users.
• Complete task: Those responsible for implementation can complete the task. The task is assigned the status Task implemented. The creator is informed by e-mail that the task has been completed.

• Delegate task: Those responsible for implementation and the creator can delegate responsibility for implementation to an employee, a role or a user group. The task is assigned the status Task delegated. The new user responsible for implementation is informed of the new task by e-mail and via the Portal header. The creator also receives a notification via the Portal header.

  See also: How delegated tasks can be handled is described in detail below.

• Cancel task: Those responsible for implementation can cancel the task. The workflow is no longer continued. The task is assigned the status Task canceled. The creator is informed by e-mail that the task has been canceled.

Task delegated

If a task has been delegated, the delegates and the creator have several options on how to proceed with the task:

• Assign task to me: If the new implementation responsibility has been assigned to a user group or a role, a user who is responsible for the task implementation can assign the task to him/herself. This user has then withdrawn the execution authorization from all other assigned authorized users. The status of the task remains Task waiting for processing.

• Forward for testing: The new user responsible for implementation can forward the task to one or more testers. The task is assigned the status Task waiting for testing. The assessors are informed via the Portal header and by e-mail that they have been assigned a new task.

  Note: You can assign the test of a general task to employees, roles or user groups.

  See also: How to proceed with a task during the test is described in detail above.

• Complete task: The new implementation responsibility can implement the task directly. The task is assigned the status Task implemented. The creator is informed by e-mail that the task has been completed.

• Delegate task: Those responsible for implementation and the creator can delegate responsibility for implementation to an employee, a role or a user group. The task is assigned the status Task delegated. The new user responsible for implementation is informed of the new task by e-mail and via the Portal header. The creator also receives a notification via the Portal header.

• Return task: The new implementation responsibility can return the to the creator. The task is assigned the status Task returned to creator. The creator is informed via the Portal header and by e-mail that he/she has been assigned a new task.

  See also: How the creator can proceed if the task has been returned is described in detail above.

• Cancel task: The new implementation responsibility can cancel the task. The workflow is no longer continued. The task is assigned the status Task canceled. The creator is informed by e-mail that the task has been canceled.

• Delete task: The creator can intervene again and delete the task. The task is assigned the status Task deleted.