The Tasks table is a global process table, and the records it holds can be linked to appear within records of other tables. This is strategic, because Task records often reflect individual tasks that relate to other tables. The Standard System Demo is currently set up to link Task records to Service Requests, Change Requests, Projects, and Assets, and is also set up to create Task records that are completely independent of other tables. It is possible to customize the setup so that Task records relate to the tables of your choosing.
By default, Tasks and the fields used for generating them are shown within Service Request, Change Request, Project and Asset records. Projects use the same methods of task generation as service requests. Task records can be created from and linked to Asset records. Asset records show all of their related Task records that have been created from other records, such as Change Requests or Service Requests.
The Task Management tables consist of the tables listed below:
Task are similar to approvals in their basic setup. They have workflow and template tables where they can be predefined, and those predefined records are used to automatically generate a set of tasks to be done in a specified order within some other record, such as a Contract or Service Request. The Task Steps table can be thought of in a similar way as the Approval Templates table.
However, there are some differences in the kind of sequencing used between the two Task and Approval tables. Tasks have a more sophisticated relationship to each other than approvals do. Approvals have a step number, and all approvals of a given step number must be completed before the next step number approvals are assigned. They can combine parallel and sequential approvals. Here, the approvals with step 1 are parallel in sequence, and they must both be completed before step 2 is assigned, and step 2 must be done before step 3 is assigned:
1- Contract Manager Approval
1- Submitter Manager Approval
2 - Finance Approval
3 - Risk Approval
Because the step number controls the sequencing, it is not necessary to relate specific approvals to other approvals in the setup, which makes approval workflows simpler to set up and maintain. But it is also not possible to have multiple branches of approvals operating in parallel but independently, as it is with tasks.
Tasks can be related to each other in more complex prerequisite structures, allowing for more sophisticated branching and triggering. The diagram shows an example of these relationships:
If an approval situation requires these complex relationships, it can make sense to use the prebuilt task structure instead of the approval structure to provide this flexibility. It is also possible to add a task type of Approval and mix approval tasks with other kinds of tasks in a specific sequence.
Within the Tasks table, the Related To field indicates the type of record the task is associated with. If you need to use tasks within additional tables, there are several steps to that configuration. This advanced functionality is best done after attending a training class or with our professional consulting team's assistance: