Overview

Like Approvals, the Tasks table is a global table that holds records that are often 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 allow tasks to be related 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 an embedded 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, while Assets allow single tasks to be created and linked to the asset, and they also show all tasks that have been created from other records (change requests or service requests) that relate to that asset.
Within the task table, the field Related to indicates what 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 table to the choice list. Then create a linked set of fields from that other table, and make these fields visibility dependent on the value in the Related to field just as we have done for the linked Service Request and Change Request fields. Then create a related table in the other table pointing to the Tasks table, and you will be able to generate tasks from there. This advanced functionality is best done after attending a training class or with our professional consulting team's assistance.

Overview of the Task Layout

Task Details Tab

The main task screen has fields for assignment, the Task Type, its Status, its Date Due, and so on.

It also includes an area for managing the related asset, if any, and a place to add working notes and to display all the running working notes that have been added:

When working on a asset-related task, the technician can click one of the buttons shown above to update the Operational Status of the asset to reflect that he has taken it offline or brought it back online.
Some tasks may have Task Steps defined. These steps are set up in the task templates. Task steps will appear as checkboxes above the Working Notes field. There are no default rules enforcing that all checkboxes are checked before completing a task, but such a rule could be easily added.

Related Tasks Tab

The Related Tasks tab shows the prerequisite tasks, if any, and allows the current task to be related to prerequisite tasks within in the same parent record. It also shows any dependent tasks (those for which this task is a prerequisite):

In the above example, we see a task that has two prerequisites already defined. The Trigger Condition defines whether this task will be set to Assigned only when both prerequisites are done, or as soon as any of them are done. Additional tasks associated with the same Service Request can be added to the prerequisites by selecting the task and clicking the Add to Prerequisites button. Either of these two tasks could be removed by selecting it in the Remove Task from Prerequisites field and clicking the Remove from Prerequisites button.
The default Status for a task is Queued when it is created. Typically a rule will set the Task to Assigned when the tasks for a record are launched (see below for more details).

Related Info Tab

This tab shows details about the record linked to the task, which will typically be either a project, service request, or change request. It provides hyperlinks to get to the source request to see more information.

Other Tabs

The Time tab allows time to be entered and shows all time entered for the task. Note that any time entered for the task will also roll up into the request to which the task is linked.
The Emails and History tabs hold the standard fields.

Use Case

Task Creation from a Template

Tasks are most often created when a user clicks a button to Generate Tasks from the record in which the tasks will be done, i.e. from within a Project, Service Request, or Change Request. Such tasks are generated from Task Templates that have been created previously and defined to be used for the particular project or service type.
When generated from a template, they will be auto-assigned to the appropriate team or person based on the task template record.
Note that currently, users are prevented from creating tasks whose task title has a comma, since this breaks some of the automation for prerequisite tasks. If a task is created with a comma, the comma is stripped out. Commas are also prevented in task templates for the same reason.

Ad Hoc/Manual Task Creation

Tasks can also be created manually outside of any other record or by clicking a button to create an ad hoc task from within one of the request records. In this case, the user will choose the Assigned Team and/or Assigned Person and may also set a Date Due, select prerequisite tasks, and so on.

Creation Automation

When a task is created manually, if it is related to a Project whose status is Completed or Cancelled, the user is prevented from saving the task.
If the Date Due is in the past when the task is created, the user is warned but allowed to correct or save the task. These actions are done by the rule: Create: All create validations.
Next a rule called Create: All Creation Actions runs, and it performs several actions based on the record the task is related to. If the task template usage is Conditional, then the Status of the task is set to Conditional. Otherwise the default status is Queued.
If the task was assigned to an individual from the related record (i.e. the Change Manager or Project Manager), then the Assigned Team is set to that person's Primary Team. If no one was assigned at all due to some failure of the template, then the Assigned Team is set to the 1st Level Support Team.
If the task is created in a Status of Assigned, then if the Assigned Person is not the creator and there is an assigned person, that person is emailed, otherwise the assigned team is emailed.
If the task is for a change request and was generated as a single task, its sequence value is set to 1.
If the task source is a task template that had prerequisite templates, then the corresponding tasks are set to be prerequisites. The prerequisites are then sorted and the one with the highest sequence value is set in another linked field called Highest Sequence.
A rule called Create/Edit: Update Sequence based on Highest Sequence than runs to set the new task's sequence value to the highest sequence plus 1.
Note that the Sequence field is purely informational. No automation is triggered based on the sequence, but it is there to provide a general idea of the order in which tasks will be triggered and completed.

Processing a Task

The person assigned to a task can add working notes to it, refer to the linked Service Request, Project, or Change Request from it, and ultimately complete the task. There are several default statuses: Queued, Conditional, Assigned, Completed, Not Needed, Failed, and Waiting for Others.
When the person has completed the task, he may change the Status to Completed and save. If there is no value in the Date Done field, the system will put the current date/time into the Date Done field. He may alternatively choose to enter a time in that field directly. The system allows the user to override the value in that field.
While working on the task, the user may enter any time spent on the task in the Time Spent and Time Description fields, then click "Add Time" to convert them to Time Entries.
When working on an asset, the Start Clock and End Clock buttons can be used to set the Actual Start Time and Actual End Time as needed. The user may also manually put values in these fields.

When a task record is saved the rule called Edit: All Edit Actions (API enabled) is run.
If the Status has changed to Completed, Failed, or Not Needed, the system updates the Dependent tasks by refreshing their Number of prerequisite tasks counts. If this was the last prerequisite, then that will trigger the next rule to assign the dependent tasks.
The rule also sets the Assigned Person, if it is blank, to the person who completed the task.
If the task is for a project, the project manager is notified of the task completion.
If the working notes field was updated, the text is copied into the Running Notes field and blanked out. And if the task is related to a change request, the notes are also updated into the Change Request's running working notes.
If the status has just changed to Assigned (by launching the tasks from the main record or by the prerequisite tasks having been completed), the Date Due is set based on specified criteria. If the task was an auto-completing task, then it is marked as Completed and the assignee notified. Otherwise, the assigned person or assigned team is notified that the task is now assigned.
When a prerequisite task is completed, its dependent tasks are updated, and if all prerequisite tasks are now completed, then the rule called Edit: Assign tasks when number of completed prerequisites meets criteria (API) runs. This rule checks if the task was conditional, and if so, checks the condition to see if it is met. If the task is not conditional or its condition is met, then it sets the Status to Assigned. Otherwise, it sets the status to Not Needed.
When all tasks for a particular record are completed or marked as failed or not needed, the person / team assigned to the main request is notified that all tasks are done.

Measuring Time for a Task

In addition to time that is manually entered, the system tracks two kind of elapsed time. The Working Hours to Complete field is set to the difference between the Date Created and Date Done, excluding the non-working hours of the assigned team and also excluding the time during which the Status was Queued, Conditional, or Not Needed.
The Actual Working Hours field measures the time between the Actual Start Time and Actual End Time, excluding the non-working hours of the assigned team.
These fields can be used in reports to see the average amounts of time tasks of specific types are taking. They can also be compared against the Template Number of Hours to Due Date value, which sets the expected working hours that should be needed for the task.

Automation and Workflow

There is a simple workflow for tasks that currently executes no actions:

Time Based rules

There are two time based rules that are set up but not running.
The first is TB: (DISABLED) Notify of upcoming task. It will notify the assigned person or team when the due date is one day away, once it is turned on. Currently it is disabled. There is a radio button at the bottom of the General tab in the table settings if this rule is desired. The schedule may need to be changed from every 10 years to something more useful.
The second is TB: (DISABLED) Set alert color to red if overdue. This sets the alert color to red when the date due has passed, so that views that use row coloring can show to users that the task is overdue.