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.