The generally accepted ITIL definition of a Service Request is “request from a user or a user’s authorized representative that initiates a service action which has been agreed as a normal part of service delivery”. (This differentiates from Incident, in that it doesn’t involve a restoration of Service.) The key part of this is “agreed as a normal part of service delivery”. Companies often struggle with what a “normal part of service delivery” means. ServiceNow further complicates this with how they built the Service Request application. If you’ve worked with the Service Catalog, Catalog Items, and the Service Request records they create, then you are probably aware of some of these challenges.

I drew this picture on whiteboards for customers for a few years and then gave it to ServiceNow training in 2013 and said “This needs to be in your curriculum. People need to understand this picture.”

The initial challenges are two-fold:

1. The Service Catalog and Catalog Items were designed to give an “Amazon” like experience. Customers select items, add them to a cart, and order them. In order to do this properly, the items need to be well-defined. You don’t go to Amazon and say, “I need socks”, press “Order” and Amazon says, “we’ll figure out the rest on the backend”. No, the expectation is you are selecting a well-defined product – size, style, color, etc. Amazon knows what they offer, which leads us to part 2 – they also know how to deliver it.
2. The Service Request is a 3-tiered record structure, with an Item-specific workflow running against the middle tier (Requested Item). The workflow generates and assigns Tasks (the third tier) based on a known delivery flow. In other words, because Amazon has defined what they are offering, they also know exactly how to deliver it.

In this way, the Service Request structure does not lend itself well to open-ended requests or ad-hoc delivery flows (aka “We’ll figure it out as we go”). The idea is that IT (or any part of the business) is delivering a known entity – they are able to define what that entity is, what it needs to ask the requester about the entity request, and what process and people need to be involved to fulfill the request for the entity successfully.

When part or all of this can’t be met, the reality is that the Service Request application (starting with a Catalog Item) may not be the correct place to build the requirement. In general, I ask the following questions of the requirement to determine if it can and should fit into a Service Request:

1. Does the use case have special security requirements? (Securing individual records gets complicated with the 3-tier record structure, and doesn’t scale well. Not to mention the notification and audit concerns.)
2. Does the use case have a known approval and delivery process? (Open-ended and ad-hoc approvals and tasks make for complicated workflows.)
3. Does the use case need the user to interact with the data after submitting the request, beyond comments? Do users need the ability to save something as a “draft” before submitting?
4. Does the use case have special schema requirements for a single entity? (e.g. Dept X needs to have 5 “special” fields on RITM to satisfy some specific need)
5. Does the use case need special notifications?
6. Does the use case require editing of variable answers after the submission of the request?
7. Does the use case have reporting requirements against what would be a variable? (ServiceNow still doesn’t do variable reporting well. Even though it is supported, it wasn’t designed with this in mind.)
8. Does the use case need an integration after the request has been submitted? (I’m shuddering at the thought of having to integrate variable data with another system.)

In general, I treat variables almost as “read-only” and un-reportable, in that a user should be able to populate them, submit them, the fulfiller looks at them to fulfill the request, and never needs to do anything else with them. Adding logic to variables is kludgy, and you don’t get a real audit history when they get edited. So when someone comes up with some complex use case that needs all this weird logic and interaction with variables, it starts to look like a Picasso painting. (As usual, this is as much art as science.)

So what to do? There isn’t a hard and fast answer to this. In some cases, when a customer is new to the platform, I have less of an issue creating a single “generic” request item that fills the need for requesters of “I don’t see what I need, can I just tell you what I need?” What this usually requires is two-fold:

1. An open-ended description that allows the requester to describe what they need. The assumption is that this almost always requires a follow-up by a service desk agent and some back-and-forth before being able to assign out work and fulfill the request.
2. A fulfillment workflow that allows for ad-hoc approvals and/or fulfillment tasks.

Keep in mind this type of request usually cannot be aligned with any delivery metrics, or if it is, will potentially skew these metrics.

In other cases, I’ve built an entirely new application to support these kinds of requests, using the Out of Box “Ticket” (ticket) table. This was for large organizations who have a well-defined catalog of items, but also fulfill a lot of requests that don’t align with a pre-built item. These are organizations whose use cases answer “yes” to many of the questions above. Once built, the records themselves can be assigned, worked and reported on like any other task-based record in ServiceNow, and queues can be managed with the ideas of “My Work” and “My Groups Work”.

So why not use Incident? An argument can be made for this, particularly if the volume is small. This is the reason for Category “Question” and Priority 5. However, keep in mind that the definition of Incident is something is broken and the goal is to restore service as quickly as possible. Often the use cases we are describing have nothing to do with restoration of service.

Regardless of the approach, the best practice is to continue to mine the requests entered for these use cases to determine if they can be converted to a well-defined Catalog Item and Fulfillment Workflow.

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.