Background: Throughout ServiceNow’s product history, there have been multiple ways to handle the “state” of a Task and its extended tables. At times, the state field that existed on Task served for all extended tables, and divergent values were done through the Choice list table. Extended tables use the Task level states unless “overridden” by table specific values in Choices. Along the way, state fields were added to the extended tables, e.g. “incident_state”, which existed completely separately from Task state. Today, both exist and are valid ways for handling state “out of the box”. But I consider this messy at best – there are odd Business rules that try to sync the task state and the extended table states. Why? Because there’s value in doing things at the Task level – like merged work queues (“My Work”, “My Group’s Work”), and reporting – “What’s happening across the enterprise?”

The challenge in this is that when trying to filter and group at the base Task level, the system attempts to build a list of all the extended table state values. If one extended table has a state of 3 (In Progress) and another extended table has a state of 3 (Closed), you’re going to get really strange results when you try to run a list of all “In Progress” tasks, because it’s going to pull in all the “Closed” records from the second extended table. (Because it’s really looking at “3”, not “In Progress” or “Closed”.)

I did some views in my Developer Instance, which I’ve not modified from “out of the box”, save for installing some plugins like Customer Service. This is a view of the State values amalgamated at the base Task level. Notice both the variety of values, and the duplication of values:

Good luck attempting to get a report of the work happening in the system by State. It’s simply not possible short of creating a massive filter based on subtask type and series of OR conditions. If I try to do a filter on Task Type is Incident and State is Work in Progress (selecting one at random), OR Task Type is Change Request and State is Work in Progress (against selecting at random), you get zero (0) results:

If I view the code behind the query, I see this:
sys_class_name=incident^state=154^NQsys_class_name=change_request^state=1

Looking at the choices in the sys_choice table for the state field (element) on any Task extended table, and grouping on the Label field, I see 54 unique values. If I look at anything with “Work in Progress” as the label, I see 3 disparate values:

This of course is exacerbated when a value has a different label across tables. I show this with the value of “3”:

The reality is the ServiceNow developers – back when these were a few folks in a back office – didn’t align on a consistent model for State values across the platform. Once the product was released and had an install base, the sub-task states were added to try and fix this problem (incident_state, request_state), but this was a band-aid at best, and actually exacerbated the situation in my opinion.

So what do we do?

When I consult customers about this situation, here’s what I tell them:

• I always recommend using the Task state (task.state) as the field that stores the state for all tasks and extended table records. Whatever we decide the task.state values should be, I’d like to keep these as the baseline by which we build other Choices states off of (for extended tables). This takes some discipline to maintain consistent values – discipline that ServiceNow hasn’t demonstrated over the years. To this end…
• Create a set of Task states that can be used universally. For each extended table, choose the states that are pertinent to it from the Task states. You don’t need to use them all. The Task states list should be enough to meet all needs. For example, you might have 15 Task states overall, and only use 5 for Incident.
• When an extended table needs a completely different state, use a substate field that fills the needs of that extended table. Keep the base Task states consistent.

What are the Benefits?

• Every script, filter and report that references the state field based on its value will not need to be changed to accommodate new values. If the concept/idea of the state is consistent, you won’t see weird behavior where you think a record should be Pending and it’s Closed. Closed will be Closed, In Progress will be In Progress, etc, even if the labels are slightly different.

What are the Challenges?

• This requires a fundamental change to how ServiceNow is built out-of-box. For each extended table whose State values are completely disparate from the Task state values, you need to change all the logic and any existing records’ state values.

Recommendation:

• Review what states exist today at the Task state level, the extended table states, and the extended state fields like “incident_state”. See if quick gains can be made by consolidation or leveraging the extended state fields.

Regardless, this is not a quick fix. Attempting to amalgamate states at the root Task level is fundamentally flawed out-of-box, and has been as long as ServiceNow has existed. In an ideal world, ServiceNow would fix this at the root level: Build a set of consistent values at the Task level, remove the extended table state fields, and allow customers to take advantage of the root Task data structure to be able to view their work world holistically. Sadly, I don’t expect this to happen: too much water under this bridge. And so we’re left to try and fix what we can.