Versions Compared

Key

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

Like Services, the 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 records that often link to and appear within the Task records, which can be linked to records in other tables. The Tasks table holds individual tasks. While it may be used for tasks of many different kinds, the system The Standard System Demo is currently set up so to link tasks can be related to Contracts, Service Requests, Change Requests, Releases, Incidents, Projects, and Configuration ItemsAssets, or but they can also be created completely independent of from 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.In the Tasks table, the Related To field indicates what type of record the task is associated with. Related records may be Change Requests, Service Requests, Projects, Configuration Items, and Releases. Service requests, releases, and change requests contain fields showing an embedded Tasks table and other fields to create tasks. Tasks and the fields for generating them are also shown within Projects and Configuration Items. Projects allow the same methods Although the Task table only links to the aforementioned tables by default, it is always possible to add or remove tables from this list.

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.

...

If you need to use tasks in additional tables, you can modify the Related To field and add the desired 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. Use the linked Service Request and Change Request fields as a model. Finally, create a related table in the other table pointing to the Tasks table, giving users the ability to create new tasks from the related table. This advanced change is best done after completing our online training course or with our professional consulting team's assistance.


...

Layout

This section reviews contains an overview of the important fields on each tab of the Task record.

Task Details Tab

...

tabs 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

...

Image shows the layout for the Task Details tab, including the Scheduling Details section.Image Removed

When tasks are generated for a change request, their Scheduled Start Time is set based on the change window start time. When tasks generated from a template move into the Assigned status, the system sets the Scheduled Start Time to now, sets the Warning Date by adding to the current date and time the Warning Target in Working Hours of the task template, and sets the Due Date field based on the Service Target in Working Hours field in the task template. The Assigned Team's working hours are used to calculate the dates.

Image shows the Service Target in Working Hours field and Warning Target in Working Hours field.Image Removed

When working on a CI-related task, the technician will see fields identifying the configuration item and two related action buttons. The action buttons let technicians update the Operational Status of the linked CI to indicate that it was taken offline or brought back online.

Cnfiguration Item details.Image Removed

...

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

Image shows the Task Steps above the Working Notes field. Task Steps are Perform baseline backup prior to patch, Build patch on standard system, and Test the result, restart the desktop and login to confirm proper functioning.Image Removed

Related Tasks Tab

...

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

...

Related Tasks tab, showing the Prerequisite and Dependent Tasks sections, with a linked record in each..Image Removed

...

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

Use Case

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.

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 

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, Emails, and History 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. If OLAs are being used, information about the OLA targets and whether they have been met are shown on this tab as well.

The Emails tab holds communication records while the History tab holds standard fields such as History, Date Created, Date Updated, and the Warning Date.

Using the Tasks Table

This section describes how to use the Tasks table. Much of the behavior of tasks may be defined in the task template from which it is generated, so be sure to review the task template section as well.

Tasks Created from a Template

Tasks are most often created when a user clicks a button to Generate Tasks in another record, for instance from within a Project, Service Request, Change Request, Incident, or Release. Such tasks are generated from Task Templates Table that have been defined to be used for the particular project or request type. When generated from a template, tasks are auto-assigned to the appropriate team or person based on settings in the task template record.

Tasks Created Manually (Ad Hoc)

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 the latter case, the user chooses the Assigned Team and/or Assigned Person and may also set a Due Date, select prerequisite tasks manually, and set other fields as needed.

Note that users are prevented from creating tasks whose Task Title has a comma, since some of the automation for prerequisite tasks would fail. If a task is created with a comma, the comma is removed. Commas are also prevented in Task Template titles for the same reason.

Automation When Tasks are Created

Several rules run on the Tasks table when new records are created. These include validations for data integrity as well as automation related to the linked records such as Incidents, Change Requests, Service Requests, etc.

Validations
  • Tasks related to a Project can't be saved if the status of the project is Completed or Canceled.
  • Tasks created with a Due Date in the past prompt a warning for the user. The task may still be saved with the past Due Date.
Automated Actions
  • The Task's status is set to Conditional if the task template usage is Conditional.
  • If the task template defines the assignee as an individual from the related record, for instance the Change Manager or Project Manager, then that person is linked from the parent record. The Assigned Team is set to that user's Primary Team.
  • If the Task is in a Status of Assigned and assigned to a person, then that person is emailed unless they are the task's creator. Otherwise, the assigned team receives the notification email.
  • The Request Priority field, if empty, is set based on the priority value of the parent record. The parent record may be an Incident, Service Request, Change Request, or Release.
  • If the task relates to a Change Request and was generated as a single task, its sequence value is set to 1.
  • If the task's source template included prerequisite tasks, then the corresponding tasks are set as prerequisites. The prerequisites are then sorted and the one with the highest sequence value is set in another linked field called Highest Sequence. The new task's sequence is set to the highest previous sequence plus one.

Note that the Sequence field is purely informational. No automation is triggered based on the sequence directly, but it is there to provide a general idea of the order in which tasks will be triggered and completed.

Processing Tasks

When tasks are first assigned, the Assigned Person or Team is notified. Additionally, the Due Date is set based on specified criteria. Tasks are assigned when they are created initially from a parent record, or when prerequisite tasks have been completed. Tasks can also be assigned directly by users for ad hoc tasks. Some tasks are auto-completing, and in that case the task is marked Completed and the assignee is notified.

Once the task is assigned, the assignee begins work. Staff can add Working Notes and refer to the linked Service Request, Project, Change Request, or other parent record from the task. The default statuses for tasks are Queued (default), Conditional, Failed / Rejected, Waiting for Others, Assigned, Completed / Approved, and Not Needed.

When the Working Notes field is updated, the text is copied into the Running Notes field and the Working Notes is erased for reuse. If the task is related to a change request, the notes are also updated in the Change Request's running working notes.

...

  • 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.
    Image Added
  • 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.

Completing Tasks

...

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

Measuring Time for

...

a Task

In addition to time that is manually entered, the system tracks two kinds 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.

...

Workflow

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

Automation

The following is a summary of the rules and validations that run when new tasks are created, either manually or from templates:

  • When a task is created manually, if it is related to a Project whose status is Completed or Canceled, 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 performed by a rule called 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, such as the Change Manager or Project Manager, then the Assigned Team is set to that person's Primary Team. If no one was assigned due to a 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, and 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 then 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.

Disabled

Image Removed

Time Based Rules

There are two time based rules that are set up but not running. These are:

  • 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.
  • 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 row coloring can show to users that the task is overdue.