The goal of each employee assigned to a task is to bring the task from initial to final state or status. Updating task status is the most common and popular way to track task progress. When employees update task state, they notify their managers of the progress they are making, while managers can use information about task states to see the big picture of their team or department performance.
Task workflow includes different states through which each task goes during its life-cycle. There are three default task states in CentriQS: “Created”, “In Progress” and “Closed”. The transition from one state to another has at least one reason which explains why the task has been updated to particular state.
When you create and save a new task, it has default state “Created” with default reason “New”. When you start doing the task, you update its state to “In Progress” with default reason “”Started”.
When you have to stop doing the task, you can update its state to "Postponed" with default reason "On Hold". Once the task is in state "Postponed" you cannot update its 'Actual' duration and add time logs manually or automatically.
When you finish doing the task, you update its state to “Closed” with default reason “Completed”, however there is a possibility to select one of the two other reasons:
You can update closed task back to state “In Progress” with default reason “Not Completed”, if, for example, you come to conclusion that it is not finished yet.
You can update closed task back to state “Created” with default reason “Reactivated”, if, for example, the task was closed by mistake.
When you set task dependency (i.e. one task cannot be started until another task is finished), successor task is automatically updated to state “Blocked” with default reason “By Predecessor”. After predecessor task get closed, successor task gets automatically updated to the previous state (the one it had before it was blocked) with default reason “Unblocked”.
When you break task down into subtasks, state of parent task gets automatically updated depending on the states of its subtasks:
Note that if at least one of the subtasks has state “Closed” with reason “Aborted”, then parent task will get automatically updated to state “Closed” with reason “Aborted” after all subtasks are closed.
There is a relation between particular task state and particular task duration field, in other words, states work in bundle with such fields as “Estimate”, “Actual” and “Remain”:
When you create a task and then update its state, you will not get any notifications (because you know what you did and there is no need to notify you about updated state). However, if you create a task and then assign it to another user, you will get notification in case this user updates task state (because you need to know what is going on with the task you are owner of).
In case the default states and reasons are not enough, you can create custom states and custom reasons. They will appear in the drop-down lists after default states and reasons. You will be able to sort and filter tasks by custom states and reasons and use them in task analytics views.
The icons of task states are displayed in the Scheduler view. Users that work with the Scheduler view can understand at a glance in what state the given task is, which tasks are still not started or already closed.