- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 06-10-2022 10:02 AM
The Task table is at the heart of The ServiceNow Platform, and can be extremely useful for seeing every(and any) type of task in an environment. However due to the nature of all the various Task Types, the baseline State Choices lead to some interesting behavior when building filters.
One of the first I discovered was reporting on the task table for active tickets: When creating a Pie Chart, a ‘Closed Complete’ wedge appears, even though Closed Complete is an Inactive State. When the pie wedge for the Closed Complete (but active) tickets was investigated, I found that it was populated exclusively by Incidents with the On Hold value.
Exhibit A
Now, I am not an Administrator for the instance I work in, and have limited access, but I was able to get a bit more information from my admin, who walked me through states In brief, each task type has a set of states and each state has an integer value assigned to it. Since I don’t have access to a Choices table I’m going to use a screenshot from this this community question as an example:
Figure 1 - from section 3 of Shloke04's Answer in Community Question: how to know the backend value of choice values on "state" field
So right away, we see that Incidents with the state Label “On Hold” have the Value 3 (this help article is years old, but this value is still true in the OOB configuration.) Simultaneously, the same Value (3) is given to Closed Complete tasks in the Task table. So, the behavior observed appears to be due to the Value mapping and the report is pulling State Label data from the assignments in the Task Table:
Figure 2 Flow of information from the INC ticket in the Incident Table through the Choice Table to the Task Table the report in Exhibit A is getting data from
Beyond reporting, this also occurs when using Filters on the Task table. Applying a filter for ‘Active’ = 'True' > ‘State’ = ‘Closed Complete’ to the Task table will yield Incidents in the On Hold State.
Exhibit B
Finding all this was interesting, but I had to ask myself - what else is this ambiguity of the state values causing and is there a way to get the correct labels to appear in a report? So I went back to the Reporting tool, built a multilevel pivot table, with Active as the Column and set the Rows to Task Type first and State second and made my next observation of unexpected behavior:
Exhibit C
On Hold appeared to work correctly (for Incidents) but now Catalog Tasks that were in fact Closed Complete appear as On Hold (and inactive)! I also saw duplicate State Labels with Integers in parentheses appended to them.
I dug in further, this time armed with a Lab instance (from attending the ITSM Fundamentals course at Knowledge ’22) – and found that the number in parentheses corresponded to the Value in the choice table for duplicate state label.
And the weirdest part? The state label displayed in the table is determined by whichever table is referenced first – if you filter for ‘Task Type’ = ‘Incident’ OR Task Type = ‘Catalog Task’, the labels reflect the Incident State Labels, while if you filter for Task Type = ‘Catalog Task’ OR Task Type = ‘Incident’, the resulting labels will reflect Catalog Task Labels.
I spoke with some more experienced people at the Knowledge ’22 Las Vegas conference (shout out to Sean McClean!) and the conclusion we drew is that this behavior is likely an emergent result of how each type of task and their states were all built independently of one another across multiple modules that were each designed and released over many iterations of the platform. Also, due to the interconnected nature of ServiceNow any changes to state values would likely cause complex problems across other ServiceNow functions and applications.
I continue to experiment with filters and reports on the Task table to see if there may be a way to make them do what I want (to give a comprehensive summary of the state of all Task-related work assigned to a given user in one report) but as of the time of writing, the most effective approach I have found would be to provide information on States is to build a report for each Task Type.
- 1,833 Views