In this article by Martin Wood, the author of the book Mastering ServiceNow Second Edition, we will see how data is stored, manipulated, processed, and displayed. With these tools, you can create almost any forms-based application. But building from the foundations up each time would be time consuming and repetitive. To help with this, the ServiceNow platform provides baseline functionality that allows you to concentrate on the parts that matter.

(For more resources related to this topic, see here.)

If Business Rules, tables, Client Scripts, and fields are the foundations of ServiceNow, the Task table, approvals, and the service catalog are the readymade lintels, elevator shafts, and staircases—the essential, tried and tested components that make up the bulk of the building.

This article looks at the standard components behind many applications:

The Task table is probably the most frequently used and important table in a ServiceNow instance. The functionality it provides is explored in this article, and several gotchas are outlined.

How do you control these tasks? Using business rules is one way, but Graphical Workflow provides a drag-and-drop option to control your application.

While you can bake in rules, you often need personal judgment. Approval workflows lets you decide whom to ask and lets them respond easily.

The Service Catalog application is the go-to place to work with the applications that are hosted in ServiceNow. It provides the main interface for end users to interact with your applications. We will also briefly explore request fulfillment, which enables users to respond to queries quickly and effectively.

Service Level Management lets you monitor the effectiveness of your services by setting timers and controlling breaches.

Introducing tasks

ServiceNow is a forms-based workflow platform. The majority of applications running on ServiceNow can be reduced to a single, simple concept: the management of tasks.

A task in ServiceNow is work that is assigned to someone. You may ask your colleague to make you a cup of tea, or you may need to fix a leaking tap in a hotel guest's bedroom. Both of these are tasks. There are several parts to each of these tasks:

A requester is someone who specifies the work. This could be a guest or even yourself.

A fulfiller is someone who completes the work. This may, less frequently, be the same person as the requester.

The fulfiller is often part of a group of people. Perhaps someone among them could work on the task.

Information about the task itself is included—perhaps a description or a priority, indicating how important the task is.

The status of the task—is it complete? Or is the fulfiller still working on it?

There is a place to store notes to record what has happened.

An identifier is a unique number to represent the task. The sys_id parameter is an identifier that is very specific and unique, but not very friendly!

Links, references, and relationships to other records are present. Is this task a subdivision of another task, or is it connected to others? Perhaps you are moving house—that's a big job! But this could be broken down into separate individual tasks.

Sometimes, a task may be as a simple as the equivalent of a Post-it note. Many of us have had something similar to "Frank called, could you ring him back?" attached to our desk. But you often need something that's more permanent, reportable, automated, and doesn't fall to the floor when someone walks by.

Looking at the Task table

The Task table in ServiceNow is designed to store, manage, and process tasks. It contains fields to capture all the details and a way to access them consistently and reliably. In addition, there is a whole host of functionality described in this article for automating and processing tasks more efficiently.

The Product Documentation has an introductory article to the Task table: https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/administer/task-table/concept/c_TaskTable.html. It also covers some of the lesser-used elements, such as the task interceptor.

To begin our journey, let's inspect the record representing the Task table.

Navigate to System Definition > Tables, and then find the entry labelled Task.In the Helsinki version of ServiceNow, there are 65 fields in the Task table. There are also many other associated scripts, UI Actions, and linked tables. What do they all do?

The Task table is designed to be extended, so you can of course add your own fields to capture the information you want. We’ll do just that in a later example.

The important fields

It is often instructive to view the fields that have been placed in the form by default.

Click on the Show Form related link to take a look.

Number: A unique identifier, it's a seven-digit number prefixed by TASK. This is constructed using a script specified in the dictionary entry.

The script uses details in the Numbers [sys_number] table, accessible via System Definition > Number Maintenance.

Assigned to: This field represents the fulfiller—the person who is working on the task. It is a reference field that points to the User table.

The Assigned to field is also dependent on the Assignment group field. This means that if the Assignment group field is populated, you can only select users that belong to that particular group.

Assignment group: This field is not in the Task form by default. You would typically want to add it using the Form Designer. Groups and users are discussed further in the article, but in short, it shows the team of people responsible for the task.Assignment group has been made a tree picker field. The Group table has a parent field, which allows groups to be nested in a hierarchical structure. If you click on the Reference Lookup icon (the magnifying glass), it will present a different interface to the usual list. This is controlled via an attribute in the dictionary.

The following screenshot shows how an hierarchical group structure would be displayed using the tree picker:

Active: This field represents whether a task is "operational". Closed tickets are not active, nor are tasks that are due to start. Tasks that are being worked on are active. There is a direct correlation between the state of a task and whether it is active.

If you change the choices available for the State field, you may be tempted to write business rules to control the Active flag. Don't. There is a script called TaskStateUtil that does just this. Try not to cause a fight between the business rules! Refer to the wiki for more information on this:

https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/app-store/dev_portal/API_reference/TaskStateUtil/concept/c_TaskActiveStateMgmtBusRule.html

Priority: This is a choice field designed to give the person working on the task some idea as to which task they should complete first. It has a default value of 4.

State: This is probably the most complex field in the table—so much so that it has its own section later in this article! It provides more details than the Active flag as to how the task is currently being processed.

Parent: This is a reference field to another task record. A parent-to-child relationship is a one-to-many relationship. A child is generally taken to be a subdivision of a parent; a child task breaks down the parent task. A parent task may also represent a master task if there are several related tasks that need to be grouped together.

Breadcrumbs can be added to a form to represent the parent relationship more visually. You can read up more about this here:

https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/administer/form-administration/task/t_TaskParentBreadcrumbsFormatter.html

Short description: Provide a quick summary of the task here. It is free text, but it should be kept short since it has an attribute in the dictionary that prevents it from being truncated in a list view. It is often used for reporting and e-mail notifications.

Short description is a suggestion field. It will attempt to autocomplete when you begin typing: type in "issue" as an example. While you are free to add your own suggestions, it is not usually done. Check out the product documentation for more details:

https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/administer/field-administration/concept/c_SuggestionFields.html

Description: Here, you provide a longer description of the task. It is a simple large text field.

Work notes: This field is one of the most well-used fields in the form. It is a journal_input field that always presents an empty text box. When the form is saved, the contents of a journal field are saved in a separate table called sys_journal_field. The journal_output fields such as Comments and Work notes are used to display them.

Work notes and Comments are heavily integrated into Connect. When you follow and subsequently chat about a task, the appropriate field is automatically updated. We'll cover more about this later.

Populating fields automatically

The majority of the fields in the Task table aren't directly used. Instead, many fields are auto-populated, through logic actions such as business rules and as default values. Others are optional, available to be filled in if appropriate. All the data is then available for reporting or to drive processes.

Some of the more notable fields are explained here, but this list is not exhaustive!

The Approval field is discussed in more detail later in the article. There are several automatic fields, such as Approval set, that represent when a decision was made.

A business rule populates Duration when the task becomes inactive. It records how long the task took in "calendar" time.

There is also a Business Duration field to perform the same calculation in working hours, but it uses calendars, which are deprecated.

The more modern equivalent is Service Levels, discussed at the end of this article.

When a task is first created, a business rule records the logged-in user who performed the action and populates Opened by. When the task is set to inactive, it populates the Closed by field. Opened at and Closed at are date/time fields that also get populated.

Company and Location are reference fields that provide extra detail about who the task is for and where it is. Location is dependent upon Company: if you populate the Company field, it will only show locations for that company. Location is also a tree picker field, like Assignment group.

Due date is a date/time field to represent until when a task should be completed.

Time worked is a specialized duration field that records how long the form has been on the screen for. If it is added to the form, a timer is shown. On saving, a business rule then populates the Time Worked [task_time_worked] table with the current user, how long it took, and any added comments.

A formatter is an element that is added to a form (such as a field), but it uses a custom interface to present information. The activity formatter uses the Audit tables to present the changes made to fields on the task: who changed something, what they changed, and when.

Recording room maintenance tasks

At Gardiner Hotels, we have the highest standards of quality. Rooms must be clean and tidy, with all the light bulbs working, and no dripping taps! Let's create a table that will contain jobs for our helpful staff to complete.

The process for dealing with a maintenance issue at Gardiner Hotels is straightforward; the need gets recorded in ServiceNow, and it gets assigned to the right team, who then work on it till it is resolved. Sometimes, a more complex issue will require the assistance of Cornell Hotel Services, a service company that will come equipped with the necessary tools. But to ensure that the team isn't used unnecessarily, management needs to approve any of their assignments.

Have a look at the following figure, which represents what the process is:

getting-things-done-tasks-img-1

These requirements suggest the use of the Task table. In order to take advantage of its functionality, a new Maintenance table should be extended from it.

Any time that a record is to be assigned to a person or a team, consider using the Task table as a base. There are other indicators too, such as the need for approvals.

In general, you should always extend the Task table when supporting a new process. Table extension gives natural separation for different types of records, with the ability to create specific logic yet with inheritance.

Now, let's create the Maintenance table by performing the following steps:

Navigate to System Definition > Tables. Click New.

Fill out the form with the following details, and Save when done:
- Label: Maintenance
- Extends table: Task
- Auto-number: <ticked> (In the Controls tab)

Then, using the Columns related list, create a new field using this data. Save when done.
- Column label: Room
- Type: Reference
- Reference: Room

Click on Design Form in Related Links, and do the following:
- Add the Assignment Group, Approval, and Room fields and Activities (Filtered) Formatter from the selection of fields on the left.
- Remove the Configuration Item, Parent, and Active fields
- Click the Save button, then close the Form Design window once done.

We want scripts to control the Approval field. So let's make that read-only. You should be in the Maintenance Table record. Find the Approval field in the Columns related list, and click on it.

Once in the Dictionary record, you will notice the form is read-only and there is a message at the top of the screen saying you can’t edit this record since it is in a different scope. We do not want to take ownership of this field.

Changing the settings of a field in the Task table will change it for all tables extended from Task. This is often not what you want! Contrarily, a Dictionary Override will only affect the selected table. Read more about this here:

https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/administer/data-dictionary-tables/concept/c_DictionaryOverrides.html

Instead, find the Dictionary Override tab, and click on New. Fill out the form with the following details, and Save.
- Table: Maintenance [x_hotel_maintenance]
- Override read only: <ticked>
- Read only: <ticked>

If you navigate to Hotel > Maintenances and click New, the Maintenance form should now look something like this:

Working with tasks

You may be familiar with a work queue. It provides a list of items that you should complete, perhaps representing your work for the day. Often, this is achieved by assigning the item to a particular group. The members of that group then have access to the ticket and should do the necessary work to close it.

In ServiceNow, this concept is represented in the Service Desk application menu.

Open up the Service Desk Application Menu. You will find these options: My Work and My Groups Work. The former is a simple list view of the Task table with the following filters:
- Active is true. This filters out closed tasks.
- Assigned to is the current user, so if you are logged in as the user called System Administrator, you see tasks where the Assigned to field is set to System Administrator.
- State is not Pending, which filters out tasks that should not be worked on right now.

The My Groups Work entry is very similar, but it shows tasks that haven't been given to a fulfiller and are still something that your group should deal with. It does this by showing tasks where the Assigned to field is empty and the Assignment group field is one of your groups. This means that when the My Work list is empty, you probably should get more work from My Groups Work.

The My Work list shows all records that are derived from the Task table. This means you will see a mixture of records from many tables in this list. It is incredibly useful to have a "single pane of glass", where all your activities are in a single place, with consistent fields and data values. They can be manipulated easily and effectively: assign all your tickets to your colleague when you go on leave with a couple of clicks!

Working without a queue

Some platforms make the use of a work queue mandatory; the only way to look at a task is through your work queue. It is important to realize that ServiceNow does not have this restriction. The My Work list is a filtered list like any other. You do not have to be "assigned" the work before you can update or comment on it.

There are many ways to find tasks to work on. This usually involves creating filters on lists. This may include tasks that have been marked as high priority or those that have been open for more than two weeks.

In many IT organizations, a central service desk team is the single point of contact. They have the responsibility of ensuring tasks are completed quickly and effectively, regardless of who they are currently assigned to. ServiceNow makes this easy by ensuring tasks can be accessed in a variety of ways and not just through a work queue.

Working socially

Social media concepts are infiltrating many aspects of the IT industry, and ServiceNow is not immune. Some useful ideas have been pulled into the platform in an attempt to make working on tasks a more collaborative experience, ensuring the right people are involved.

Chatting with Connect

Connect Chat focuses on bringing fulfillers together. The UI16 Connect sidebar is easy to activate and use, letting you swap text, pictures, videos, and links easily and efficiently.

The real benefit that ServiceNow brings with Connect is the ability to create a record conversation especially around tasks. This allows you to have a chat session that is connected to a particular record, allowing your conversation to be recorded and embedded. In Gardiner Hotels, the experienced staff probably already know how to deal with common maintenance tasks, and so by giving a newer team member easy access to them, our guests get better service.

The Follow button is already available on every table extended from Task. But what’s special about Connect with the Task table is that the messages are added either as comments or work notes. While this is very useful for monitoring the progress of multiple tasks at the same time, record conversations are far less private: many users will have access to the activity log that shows the chat conversation. It probably isn’t a good idea to share a meme in the work notes of a high-priority task.

Additional comments and work notes are discussed later in the article

Communicating some more

In addition to Connect Chat, ServiceNow provides several other options to share information.

Connect Support allows requesters to ask for help via chat. Generally, the requester initiates the session through a self-service portal, by clicking on a button and entering a queue. A Service Desk Agent can then work with multiple fulfillers in the Connect window.

Older versions of ServiceNow had chat functionality, but it was limited in capability—it did not support in-browser notifications, for instance. Help Desk Chat was also limited by having to use a custom page rather than having it integrated into the main interface.

Both Chat and Connect use the same tables to store the message; they should not be used at the same time. More information is available in the Product Documentation

https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/use/using-social-it/concept/c_HelpDeskChat.html

Live Feed gives a Facebook-wall type interaction, where all types of users can read and add messages. This can be used as a self-service system, since the messages are searchable and referenceable by copying a link. It is a communication mechanism that allows users to be as involved as they'd like. Unlike e-mail, Live Feed is pull-style communication, where users must go to the right place to receive information. To ensure it gets checked regularly and is therefore most beneficial, the right culture must be cultivated in a company. Navigate to Collaborate > Live Feed to use it.

Table Notification creates Chat and Live Feed messages automatically based on conditions and configurations. For example, during a service outage, the service desk may want an automatic communication to be sent out, alerting people proactively. Check out Collaborate > Feed Administration > Table Notifications.

Summary

In this article, we discussed looking at the Task table in which we covered the important fields, populating fields automatically and recording room maintenance tasks. Also covered working with Tasks in which we discussed working without a queue and working socially.