How to use Workflow
The video tutorial
Tips and tricks
The workflow settings can be accessed in More: Administration: Workflow.
Here you have to choose a role and what changes can this role make on a task in a particular type. Click on the green "Edit" button and the options will reveal. In the left column is the list of all current statuses a task might have, while on the right side are "New statuses allowed" with checkboxes, which might be checked (status allowed) or unchecked (status unallowed) for selection when the current status, role, and task type have already been set on the task. According to the below example, when a task is in type Task, Project Manager can only change the status from New to Realization, nothing more.
Field permissions stand for what a particular role may fill in or what he has to fill in per various task fields. Choose a role and task type for which these permissions apply. You can set the permissions for standard fields and also for custom fields. As shown in the above example, if the field has a red star next to it, it is a globally required field that has to be always filled in no matter your role. The field without the red star can be set as:
- Blank (the field can be either filled in or not)
Tips and tricks
If a status is not to be used under a task type at all, make sure to deselect respected checkboxes in a cross formation.
Use case 1 - Configure a chain of approval
Below is an example of how the chain of approval works. Each role (e.g. representative, manager, technician, etc…) may only change the status of a task in a certain way that ensures the process is smooth and there are no internal conflicts. For example, only the representative who is in direct contact with the customer may change status to “Done” once the whole process is finished and once the client has been informed. While only manager may approve or decline particular requests initiated by the client.
The client initiates a new request (task), the representative then replies to the client that the request has been forwarded for further approval and marks it with the “Waiting for approval” status. The manager has a list of all the requests (tasks) which are marked as “waiting for approval”. Once he decides whether or not the respective request shall be approved for further action(s), he then changes the status of the request (task) accordingly to either “Approved” or “Declined”.
The technician has a list where all the “approved” requests are shown. He continuously works on these and once he is finished with any, he changes its status to “To check and invoice”. At this moment, the request (task) is shown in the representative´s list who double-checks the work of the technician. If all the requirements of the client are met, he marks the task as “done” and informs the client accordingly.
Use case 2 - Force users to enter important data - required
In order to obtain certain data that are crucial to you, you may make certain fields mandatory, this can be done by setting such a field to “Required” status. For example, when you need the date of birth of your client (e.g. in order to establish whether the client is of legal age) you may set the “Date of birth” field as “Required” so that the client may not proceed without duly filling-in such field first.
Use case 3 - Disable unauthorized users to change important data - read-only
Be careful as subject and description must be enabled in a new task. Certain users are allowed only to perform certain actions and they may not edit or remove important information, this can be achieved by enabling the “Read-only” mode.
For example, if a customer fills-in his or her date of birth, then such field may be set to a Read-only mode in order to prevent an accidental loss of such data. Alternatively only a manager (or any other suitable person) may be enabled to change/remove this data while others cannot.
Use case 4 - Disable unnecessary status on the type of work where you do not need it
Status “code review” is important for the IT department, but not for other departments. IT specialists will be able to use the "Code review" status, but users from other departments will not have access to it.
- When the project field is set as "Read-only", you will not be able to move tasks because project field on the task would need to change in such a case.
- When moving a task in a particular type into another project that does not allow this task type in the project settings, the type of the task will be changed automatically to the first allowed one in the list.
- When having enabled the option "By closing parent task, close also subtasks" in Administration » Settings » Task tracking, then parent task's status is also applied to its subtask's status even when the status for the subtask is disabled by Workflow settings.