Like Approvals, the The Tasks table is a global process table that holds records that , and the records it holds can be linked to and appear within the records in of other tables. The Tasks table holds individual tasks. While it may be used for tasks of many different kinds, the system 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 tasks Task records to Service Requests, Change Requests, and Projects, as well as to and Assets, or to be and is also set up to create Task records that are completely independent of other tables. It is possible to modify customize the setup to so that Task records relate tasks to records in any table and to show embedded tasks in any other table.to the tables of your choosing.

By default, Fields related to task generation and an embedded Tasks table, labeled Tasks, are shown in service requests and change requests for services that include tasks. Tasks and the fields used for generating them are also shown within Projects and AssetsService Request, Change Request, Project and Asset records. Projects allow use the same methods of task generation as service requests. Assets allow single tasks to Task records can be created from and linked to the asset, and show all tasks 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:

Tasks vs. Approvals

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 change requests or service requests, that relate to that asseta 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:

Image Added

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 what Related To field indicates the type of record the task is associated with. If you need to use tasks within any additional tables, you can modify this field and add that 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:

1. Open Setup [Tasks]. 
2. Navigate to the Fields tab.
3. Modify the Related To field by adding the desired table to the choice list.

...

2. Create a linked set of fields sourced from

...

1. the table in step 1.
2. Make these fields visibility dependent on the value in the Related to field

...

1. .
2. Navigate to the table from step 1. Create a related table field pointing to the Tasks table.
3. Determine what kinds of task generation you want to support: ad hoc, workflow based, user selected, or a combination.  Depending on the requirement, you may need an intermediate table where that generation method is defined, or you may be able to use the existing Task Workflow and Task Templates tables, with the new Related To value added to each of them, to define the task workflows that you need.
4. Add the relevant fields to your process table. This allows you to generate and manage tasks, as well as update the Task table rules to process tasks for this new table.

...