The Tasks table is a global table holding records that can be linked to and appear within the records in other tables. The Tasks table holds individual tasks. While it may be used for tasks of many different kinds, the system is currently set up to link tasks to Service Requests, Change Requests, and Projects, as well as to Assets, or to be completely independent of other tables. It is possible to modify the setup to relate tasks to records in any table and to show embedded tasks in any other table.

Fields related to task generation and a related Tasks table, labeled Tasks, are shown in service requests and change requests for services that include tasks.

Tasks and the fields for generating them are also shown within Projects and Assets. Projects allow the same methods of task generation as service requests. Assets allow single tasks to be created and linked to the asset, and show all tasks that have been created from other records, such as change requests or service requests, that relate to that asset.

Tasks vs. Approvals

Tasks are similar to approvals in their basic setup.  They have workflow and templates tables where they can be predefined, and the workflows/templates 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.

There are some differences in the kind of sequencing used between the two tables.  Tasks have a more sophisticated relationship to each other than do approvals.  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, such as: 

1- Contract Manager Approval

1- Submitter Manager Approval

2 - Finance Approval

3 - Risk Approval

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.  

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.  A task diagram can show 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.

Linking Tasks to Other Tables

Within the Tasks table, the field Related to indicates the type of record the task is associated with. If you need to use tasks within any 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.