Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The Tasks table is used within several other process tables to automate and track tasks. The Tasks table is a global process table that holds Task records, which can be linked to records in other tables. The Tasks table holds individual tasks. The Standard System Demo is currently set up to link tasks to Contracts, Service Requests, Change Requests, Projects, and Assets, but they can also be created completely independent from other tables. Although the Task table only links to the four aforementioned tables by default, it is always possible to add or remove tables from this list.

Info

Fields related to task generation and

...

the related Tasks table

...

are shown

...

in Service Requests and Change Requests for services that include tasks.

Tasks, and the fields used for generating them, are also

...

available in Projects and Assets records.

  • Projects allow the same

...

  • method 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.


Layout

We'll begin with This section contains an overview of the important tabs , and some of their fields, of a Task record., along with some of the more important fields:

  • Task Details: Contains fields defining the nature of the task, such as Task Type, Task Summary, and the task Description. It also shows task Status, Assigned Team, Assigned Person, and the Date Due. The main task screen also includes an area for managing the related asset, if any. Tasks based on a template may be defined to have specific task steps, and if the task has such steps, they appear with checkboxes in the Working Notes section. There are no default rules enforcing that all checkboxes are checked before completing a task, but such a rule could be added. The user can add working notes at any time, and these will be added to the running history of all working notes: When working on an asset-related task, the technician can click one of the buttons shown above to update the Operational Status of the asset to reflect that it has been taken offline or brought back online.  
  • 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, that is, tasks for which this task is a prerequisite. When a task has two prerequisites that are 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. When tasks are launched, any task without a prerequisite is automatically set to Assigned (see below for more details).
  • Related Info 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.

...

Task records can be created by users in the Admin, Admin Import, Base ServiceDesk, Business Admin, Contract Manager, Contract Owner, Internal Customer, Marketing, Project Manager, Sales, and Service Managers groups. Although Tasks can be linked to one of several other tables, they are generally all created and processed in similar ways. When Task records are created, several automated actions occur. Task records are created:

  • By clicking the Generate Tasks button from the related record, such as a Project or Service Request record.
  • Manually by users in the Task table

...

Creating Tasks

In the Standard System Demo, Task records can be created in in the following ways:

  • Predefined Task Workflow: A workflow selected on the process table is used to trigger the creation of Task records when a user clicks the Generate Tasks button using the related Task Templates.
  • User Selected Tasks: The user selects the necessary tasks from a multichoice field of Task Templates in the process table. The selected Task Templates trigger the creation of Tasks records when the Generate Tasks button is clicked
  • Ad Hoc Tasks: The user clicks The Add an Ad Hoc Task button in a Contract where Ad Hoc Tasks are enabled on the Contract Type, or manually by clicking the New button in the Task table.

Task Details Tab

It's important to ensure the following fields of the Task Details tab are configured properly when creating Task records:

  • Assigned Team / Assigned Person: When a Task record is generated from a Task Template record,

...

  • it is automatically assigned to the appropriate team or person

...

  • designated on the Task Template record. Refer to the

...

  • Task Template section for more information on how Task Templates define the parameters used in generated Tasks. If the task is created ad hoc by the user, the Assigned Team should be set by the creator. If no Assigned Person is set, any member of the team is able to update the task. 
  • Date Due: For Tasks generated from a Task Template, the Date Due is set when the status changes from Queued to Assigned based on the working hours of the Assigned Team. When creating an Ad Hoc Task, the Date Due should be set manually.
  • Assignment Trigger: For Tasks generated from a Task Task Template, the Assignment Trigger will be populated from the Task Template. When Prerequisite Tasks are used, the Task will become assigned when the prerequisite is completed. For Ad Hoc Tasks, the creator can define what the Assignment Trigger that will be used to set the status to Assigned and notify the Assigned Team or Person.
    • Creation / No Open Prerequisites: Chosen when the task should be assigned immediately on create.
    • Date: Fixed dates and dates Relative to the Contract can be used.  
    • Status: The Task will change to assigned when the contract status changes to the selected status. 

Working the Task 

Users are prevented from creating tasks with a comma in the title, 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 template titles for the same reason.

The person assigned to a task can add working notes to it, refer to the linked Contract, 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 user completes the task, they change the Status to Completed/Approved and save the record. If there is no value in the Date Done field, the system will put the current date/time into the Date Done field. Alternatively, the user may enter a time in the Date Done field directly. 
  • 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 a 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 field.
    • 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.

...