Handling exceptional task situations

During the processing of task, exceptional situations may arise that require a deviation of the normal course of action. The respective actions are offered as [buttons] in task view and as actions in the action and context menu of the task under   Task . What is offered here in detail depends on the role of the user as contractor or requestor, of course.

  Task    Object : Input data contain mistakes. In task view, contractors may enter their ob­jections below the faulty input data fields and [Object to task]. Objections to in­put data may also be entered and saved using [Save form] without actually object to the task. Such preliminary objections are not visible to the requestor, as long as the ac­tion [Object to task] has not been executed; they may be changed or de­let­ed at will.

After the action the objections are accessible to the requestor. After a correction of the in­put data, the requestor may request the task again.

  Task    Withdraw Request : Task needs to be re-specified. The requestor may [With­draw task request] in order to ,e.g., specify additional input or output data or enter dif­ferent values for existing input data fields. After a correction, the task may be re­quest­ed again.

  Task    Request Correction : Output data contain mistakes. In task view, the requestor may enter objections below the faulty output data fields and [Request task correction]. Ob­jections to out­put data may also be entered and saved using [Save form] without actually requesting task corrections. Such preliminary objections are not visible to the con­tractors, as long as the action [Request task correction] has not been executed; they may be changed or deleted at will.

After the action the objections are accessible to the contractor(s). After a correction of the output data, a contractor may finish the task again.

  Task    Withdraw Results : Output data contain mistakes. A contractor may [With­draw task results] in order to correct the output data of the task. After a correction, the task may be finished again.

  Task    Reject : Contractor is not able or willing to execute the task (not his or her duty, on leave). A contractor may [Reject task] and the task state switches to rejected.

A rejected task may be changed by the requestor and started again. Possible changes in­clude the assignment of new contractors and the definition of new data fields.

  Task    Uncommit : Commitment to task execution needs to be revoked. A con­trac­tor may undo the commitment via [Uncommit to task]. The contractor may then object to the task, reject the task or finish it in spite of revoking the commitment. The requestor may withdraw or cancel the task or decide to wait for task execution.

  Task    Cancel : Reason for task execution is no longer valid. The requestor may [Cancel task]. A cancelled task is not processed further. The requestor may, however, reopen the task, change it and start it again (or simply restart it at a later point in time).

  Task    Forward : Other users are more suited for task execution or supervision. Both con­tractor and requestor may [Forward task] to other users. If one forwards a task, one can nevertheless stay contractor or requestor by checking the respective box in the ac­tion form.

There are two more actions by which tasks in a final state (accepted, cancelled or completed) may be reused again.

  Task    Reopen : The requestor puts the task into a state where all task specifications may be changed, in order to start the task again with the changed specifications (con­trac­tors, input data, time frame)

  Task    Restart : The requestor simply restarts the task with the specifications given. Note that eventual specifications of a deadline and input data values remain as is.

The requestor may add further contractors to a task or may remove existing ones by

  Task    Assign . This action is not possible in final states of a task and when the current con­tractors are working on the task (states requested and committed). In some task states (e.g. rejected) also contractors may invoke this action and can leave a task this way.

Apart from forwarding and assigning all of the above actions have no action form, i.e. the actions are executed straight away, because they consist of a state transition of the underlying task. The data necessary for the action (comments for the audit trail, objections, input and output data) have to be entered in task view (and possibly saved via [Save form]) before the action is invoked. During the action, only the availability of the expected data is checked. Missing data lead to an error message or a warning in form of a hint.

The state transitions of a task that are due to task actions are summarized in the following table.

 

Action	State before action	State after action
request	initial, objected, withdrawn, rejected, reopened	requested
commit	requested	committed
finish	requested, committed	finished
object	requested	objected
uncommit	committed	requested
withdraw results	finished	committed
reject	requested	rejected
accept	finished	accepted
request correction	finished	committed
cancel	every state except accepted and cancelled	cancelled
withdraw request	requested, committed, finished	withdrawn
restart	accepted, cancelled	requested
reopen	accepted, cancelled	reopened

 

If an exceptional situation arises during task processing, which deviates from the normal course of action (request – commit/finish – accept), this is indicated by a specific task icon in a folder listing or the personal task list. The different task icons have the following meaning:

   represents a task that has not yet been started or is being worked on without having been finished.

   represents a task that has been finished. Also the task states accepted and completed (by the requestor) show this icon.

   represents a task that has been rolled back by actions such as an objection, a with­draw­al of results or a request for correction. When the task returns to the normal course of pro­cessing, e.g. by actions such as a renewed request after an objection or a renewed finishing after a request for correction, the task is represented again by the icon for tasks in processing or tasks done.

   represents a task that has been cancelled. Such tasks may be started again, with or with­out changed specifications (action reopen and restart).

In task view, the possible actions are offered as buttons. The actions offered depend on the task state and the role of the user as contractor or requestor. With a task in state requested, e.g., as contractor you could commit to, finish, object to, and reject the task, as requestor you could withdraw the task request and cancel the task altogether; in both roles you could for­ward the task to other contractors or requestors.

If you unfold the section ‘State’ in task view, you will see the possible states of the task. The current state is indicated in faded orange. States that may be reached by a contractor action are coloured blue, states that may be reached by a requestor action are coloured green. By click­ing on a target state you may also invoke the respective action.