It’s been a few years since I wrote Part 1 of this article, going through the history and evolution of the ServiceNow platform, and the morphing of the company strategy from platform to product. After working with multiple clients in the meantime, and reading lots of new marketing and going through many platform release upgrades, I thought it time to revisit the subject with new perspective and analysis.

A quick recap: In the early 2000s, ServiceNow (nee “Glide”) was envisioned and built as an extensible business workflow platform, designed to replace paper and manual processes, but without a defined business application built-in. The idea was that businesses would analyze their own processes and automate using the platform components. Once this didn’t catch on, the SN founders built an application suite on top of the platform using what they knew – ITSM. This caught on, and in the subsequent years both customers and ServiceNow have used the extensibility of the platform to build and solve countless business processes problems. As ServiceNow itself has gone public and had multiple leadership changes, the company has shifted development, sales and marketing focus to products it builds on top of its own platform. This is why most discussions around new releases are around Products, and not platform enhancements.

While this all may be natural progression for a company that goes public and has to answer to the markets and short-term financial interests, it poses some issues for those attempting to use ServiceNow as a platform rather than a series of products.

Buy versus Build

In the early days of ServiceNow, the process for implementing a business process solution was generally straightforward (other than specific ITSM processes, which were built in). As a consultant, you would listen to the business problem that needed solving, then design and implement a custom* solution using the platform components provided (see Part 1 for more detail). There wasn’t a longer discussion or decision required for build versus buy, since the platform was designed to be built upon. ServiceNow provided the components to build the tools (applications) to solve business problems, and the licensing was based on fulfiller versus requester. There was no further buy versus build decision to be made.

*NOTE: Although this could spawn an entirely separate discussion, I want to point out that in the ServiceNow world, “custom” is not a bad word, though it is often seen as such.  In reality, building a new application using the platform components ServiceNow provides is doing exactly as the founders intended.  It is also not really “custom” in the true sense of the word. It is simply a new way of using the components provided.

Simplification by Obfuscation?

The nature of strategizing control over flexibility means you take the power of the platform out of the hands of those who are best equipped to take advantage of it. This has been true long before ServiceNow and will continue to be true long after, but I believe it is exacerbated in the ServiceNow space by the factors previously mentioned: market forces, management changes, market strategies, misinformation and misconstrued information. Over the years as ServiceNow has moved from a ticketing system to a strategic platform for companies, I’ve watched as C-level executives have injected common phrases like “stay out of the box” and “minimize upgrade efforts” into the lexicon. I can only assume these come from history with other platforms and reading industry studies, rather than from deep knowledge of what this really means for their ServiceNow implementation. I also assume because those who are making the financial decisions are saying these things, that they become both gospel and strategy for those who have a vested interest in their decision-making.

I liken what ServiceNow has done to the platform to using WordPress for website development, rather than DreamWeaver. The latter is a framework that gives you pre-built components that experienced developers can use to build custom websites faster. The former is more for non-developers to implement fully pre-built websites with a small to moderate ability to make configuration changes. But for an experienced website developer in certain circumstances working with WordPress can be more challenging because things that could easily be modified in CSS aren’t always accessible. In this way, WordPress makes it easy to deploy a website that fits their model, but makes it far more difficult to make what are often necessary changes after the fact.

Business Example:

Here’s an example of what I’ve been describing:

Business Requirement: A need to manage company events such as luncheons, meetings and guest visits. The company wants to use their ServiceNow investment and the platform tasking and workflows to do so.

Platform Solution: A ServiceNow architect uses the Task application model to extend to a new Task Type called “Event”, creates a Record Producer to intake customer needs (available in the Service Catalog), builds sub-tasking records and initiates them with a workflow based on state changes to the parent Event. Form and list views, notifications and reports are configured to meet business needs. Security for the new application is layered on as needed. Any specific business requirement can be implemented without concern for “breaking” out of box solutions, and is completely upgrade-proof (ServiceNow doesn’t care about net new applications and components – they are completely ignored in upgrades).

“Out of the Box” Solution: The customer ServiceNow team is told to stay “out of the box” and so attempts to build the solution in Service Request with a Catalog Item for intake. The Event data takes the form of many variables on the Requested Item. The workflow is driven off of variables, and Catalog Tasks are initiated by the workflow. The ServiceNow team has to customize the Request and Task forms for Event needs, creating maintenance issues – the application looks and functions one way for “normal” Service Requests, and a different way for Event Requests. Forms, lists, reports, notifications, security are all doubled with mutually exclusive conditions. Subsequent implementations like this use case in Service Request further complicate the configurations and maintenance.

Product Solution: A ServiceNow Account Manager hears “buzzwords” from the customer regarding their business needs and finds an out of the box product to license them. The customer installs the new product and demos for the business. Stakeholders find that the product only partially aligns with their needs. The business has to make a decision to either customize the ServiceNow product for their needs, or go through a rigorous and costly OCM cycle to change the way their business works to fit the ServiceNow product. If choosing the former, the company loses the ongoing maintenance benefits of staying “out of the box”, while still paying new licensing charges. Anyone who has worked in corporations knows the latter requires an incredible sales job to accomplish – businesses DO NOT like to change!

If you’re intuiting the conclusion I’m reaching with this example, you realize the irony is that what most would call the “custom” solution is actually the solution with the least development friction, the least technical debt, and the least upgrade concerns.

Conclusion

We’ve reached a concerning level of misinformation and mischaracterization of design and development decisions as ServiceNow has changed both their platform focus and marketing strategy. But what ServiceNow cannot change is the fundamental nature of the platform any product they build and market is based upon. Those architects and developers who truly understand this fundamental nature are much better equipped to deliver real value to their customers via shorter development cycles, maintainability, and upgradeability. Remember: “custom” is not a bad word!

Tiering Examples

1. User in building 3, floor 2, Accounting department reports an issue with accessing SAP. Root cause is a misconfigured switch port.

• Tier 1: User calls the Help Desk. A support agent opens a support ticket and does some basic troubleshooting – reboots, logs out and in. After 10 minutes, the agent tells the user they need to escalate and ends the call. The agent assigns to a SAP support group. After a few hours, an SAP engineer sees the ticket and begins to ask around if there are any known issues currently. He also confirms he can access SAP and notes no issues in the logging. He IMs local support in building 3 and asks if they can do a remote session. After some troubleshooting, they realize all computers on floor 2 are having trouble accessing some network resources. The ticket is reassigned to Networking. The next morning, the Networking team picks up the ticket and reads through all the notes. They check with the team verbally and via IM to see if any changes went in recently. After a few hours, they realize there was a switch card installed to fix a hardware issue 2 days ago. They begin to troubleshoot and by early afternoon, find the misconfiguration and fix it. They assign the ticket back to the Help Desk and the level one support team checks with the end user that service has been restored before closing the ticket.
• Tier 5: User submits an incident through the Self Service portal with a high impact, after confirming several members of his team are having the same issue. The incident is marked medium priority and tied to the SAP service and auto-routed to SAP support. SAP support picks up the incident and checks the SAP system for issues, seeing none. They view the CMDB map to check for upstream issues, and see that there are other incidents and a change tied to the network switch in building 3, floor 2. They change the affected CI to the switch and the ticket is auto-reassigned to the networking team, and change the priority to high. The networking team’s SLA-based queue dashboard moves the incident to the top, and the incident is assigned to a level 2 engineer automatically. The engineer, viewing the same CMDB map, makes the incident a child of another incident opened against the same switch. The team sees the change, and finds and fixes the configuration error based on the implementation notes for the Change. The parent is closed and the resolution flows to all children. Service is restored within 2 hours. Management reviews the change and sees a gap in the review process that allowed the issue to occur, and the change templates are changed to prevent the issue in the future.

2. A manager in Sales needs to onboard a new sales rep working remotely

• Tier 1: The manager emails the Help Desk with the details about the new rep. A support agent opens a support ticket and fills out what was provided in the email, but has to contact the manager to get additional information. After several back-and-forths, the agent begins to email other teams with the ticket information so that they can fulfill the portions they are responsible for, e.g. Procurement to get the hardware and Application Support to set up accounts. The agent has to manage the disparate fulfillment processes through phone, email and IM. Because of different lead times, it takes 8 days until the agent has everything she needs. Meanwhile the rep starts on day 10. The agent sets up the laptop, logs in as the new rep, sets up the applications, and ensures access. She then works with shipping to get the “office setup” sent to the new rep. The new rep receives everything after 13 days.
• Tier 5: The manager submits an Onboarding request through the Self Service portal, filling out all required information, including choosing available hardware stored in the system by department. The system also contains a master list of applications by department. The system’s fulfillment workflow for Onboarding sees the new rep is part of Sales, orders the Sales laptop automatically from Procurement, and auto-provisions all enterprise-wide and sales specific applications. Procurement uses Asset and Inventory management, and has hardware in-stock for such requests. The hardware is delivered to the Service Desk, and an Agent, who owns the master request, sets up the laptop for the rep and confirms the application access that has already been provisioned. The entire process takes 2 days. The Agent works with shipping to ensure the “office setup” is delivered the day the rep starts their position with the company. The system, based on the request, keeps a record of all hardware and application access received, and uses that data for managing shutoffs and reclamations when the sales rep transfers to another department or leaves the company. Management uses the requester’s and fulfiller’s departments and cost centers to report on how much service is being provided, and to whom, to manage budgets and do chargebacks.

Tier 1 vs. Tier 5

Tier 1

Characterized by:

• Lack of self-service
• Centralized help desk
• Unrelated tickets
• Tribal knowledge
• “Catch as catch can” prioritization and resolution

Tier 5

Characterized by:

• Multiple service channels
• Distributed, specialized support groups
• Prioritized and correlated ticket queues
• Synchronization between core data, knowledge and CMDB to align, diagnose and resolve and fulfill
• Automation, orchestration and integrations to fulfill and synch systems

What I hope is an obvious conclusion from all this is that ServiceNow is able to achieve all these tiers. Many systems that were designed as ticketing systems first can reach the first, second or perhaps third tier, but struggle to achieve the goals of tiers four and five. Because ServiceNow was designed as a platform first, and ticketing, specifically ITSM ticketing was layered on top, it is flexible enough to achieve any desired level. When Service Management is viewed holistically – from a platform perspective and not just a series of unrelated operations applications – it has the ability to help your company become a strategic leader in your industry. (Wow this sounds terribly like marketing – sorry about that!) So why drive a Cadillac? This is why!

Happy transforming!

I had a client recently refer to ServiceNow as a “Cadillac Escalade”, and that they “just needed a Kia”. This is certainly a long way from when I started at ServiceNow in 2010 and the company and the platform was still just emerging from its “gutsy startup” phase. We’ve now reached the point where ServiceNow has become a “gold standard” in cloud platforms and Service Management, and customers are having to decide if they can afford such a high-end solution.

Anyone who has spent time in business realizes that many decisions are made strictly on financial conclusions, or at the least, what is the minimum required solution for the minimum price. While this exercise is black and white, it’s often overly simplistic and short-sighted.

I’d like to use the remainder of this article to talk about the decisions made about using ServiceNow as your Service Management platform: What do you get out of it, what do you want to get out of it, and are you thinking about both in the right way?

Deciding what Service Management is to your business

For much of IT’s history in business environments, upper management’s view of it (and often the whole company’s) is mainly or purely operational: While it automates a previously manual process, it is there simply to “keep the lights on”, and isn’t core to the company strategy. As a subset of IT, Service Management serves the same function: Ensure people can do their work, and speed up the process of getting people what they need where possible.

Only recently have I started to see a shift in philosophy where companies and company decision-makers start to view IT and Service Management strategically: How can this business function actually be leveraged to make us more competitive, increase our margins, allow our people to focus on strategy and not day-to-day repetition. Let’s explore what this means. The following image shows the upward pyramid of Service Management from operational to strategic:

Here’s each tier in greater detail:
Tier 1
Organizations have a central mechanism for taking in issues and requests, assigning them, and working them through to completion. Issues and requests are lumped together; customers and fulfillers view everything as a “ticket” to get reported and completed. Processes are manual: the customer calls or emails, queue managers or general fulfillers assign out the work. No SLAs are defined or tracked – work is done “catch as catch can”. Knowledge and solutions are tribal. No CMDB exists or is leveraged for ticket alignment. No attempt to recognize patterns or recurrences. Reporting is basic and often compiled and manipulated “just in time”.

Tier 2
The central mechanism begins to delineate between types of requests, and defining SLAs around each. For example, an issue preventing a person or persons from doing their job is prioritized over a request for a new software installation. Customers have other interfaces to submit and view their issues and requests – portal, mobile apps, etc. Fulfiller queues become better defined and therefore easier to assign. Management starts to standardize reporting and it becomes more real-time in nature. Knowledge begins to be documented. A CMDB is started for aligning issues and requests with physical and logical infrastructure. Fulfillers begin to recognize and report patterns.

Tier 3
Based on information in submissions, some routing is automated, bypassing the initial queue. SLAs begin to be used to measure performance and enforce accountability. The customer experience becomes both broader and more intuitive – more information and paths to get service exist, but the interfaces are easy to navigate and the correct information is presented at the correct place and time. The CMDB becomes core to understanding and analyzing the service environment – where are issues arising and how is it tied to the broader environment? Reporting starts to move up and down the enterprise hierarchy and is not just limited to single service areas or tiers. Knowledge management processes become defined to ensure knowledge is relevant and up-to-date.

Tier 4
The service desk becomes de-centralized as the CMDB and other mechanisms define and route tickets to the correct initial fulfillment groups (bypassing the generic “service desk” or “help desk”). Correct and available knowledge begins to deflect ticket creation as customers are able to self-serve. Other tickets, particularly requests, are auto-fulfilled (require no human interaction) with orchestration. CMDB relationships are defined allowing fulfillers to see impact across services and the enterprise infrastructure.

Tier 5
All ticket types are defined based on the information presented and the service required – the “right tool to get the job done”. SLAs are defined by type and measured, viewed and accountability exists for meeting them. Almost every submission is routed to a minimum level 2 support group based on the information provided. Fulfillment flows are defined and automation/orchestration is used wherever possible, and fulfillment flows are not implemented without exploring and understanding what automation is possible. CMDB and core data drive the routing, the fulfillment flows and the reporting. Fulfillers leverage the CMDB relationships to understand issues and change impacts across the enterprise. Reporting can be done from the fulfillment teams and ticket type level all the way up to the enterprise, based on available core data. All opportunities for self service and ticket deflection mechanisms are implemented and exposed to the customer. Knowledge is cultivated, managed, standardized and available to the correct audiences. The service management system becomes a system of record for all services delivered and aligns with systems of truth for devices, licensing and access.

Where do you want to be in this tiering?

As stated earlier, it’s much easier to do a cost-benefit analysis of Tier 1. But the real ROI comes from leveling up towards Tier 5. ServiceNow’s flexibility allows you to reach any of these tiers, so a goal of Tier 5 is very attainable. When your employees are no longer focused on day-to-day operational concerns, but rather focus their energies on business improvement, strategic initiatives and outside the box thinking, your business becomes a leader.

In Part 2, we’ll examine the key differences between Tier 1 and Tier 5.

* – A play on the famous James Carville quote about the economy, not implying that ServiceNow folks are stupid

As many know, ServiceNow has been through 4 CEOs: Fred Luddy, Frank Slootman, John Donohoe, Bill McDermott; and as most know, Fred was the founder. Fred at his heart is a developer. (From Broke To Billionaire: How Fred Luddy Built The World’s Most Innovative Company) From Forbes:

Luddy hit on a revolutionary idea he had learned from three decades of programming: As the company’s name suggests, he’d deliver office services over the internet, on a subscription basis (monthly, per customer), updated easily without requiring customers to manually download software from disks on different operating systems. As this was 2003, Luddy proved to be a software-as-a-service pioneer, pushing a user-friendly interface designed for the average office worker…
The market’s response: “Meh.”

“We had this really great, simple platform for creating workflows, and we would go to people and say, Hey, you can do all these things with this, and they just weren’t interested,” recalls Luddy, who at one point sold a car to make payroll. “So we went back and said, Okay, we say this is this great tool for doing things like IT-support management, so why don’t we back that up and make an IT-support product?” This time the market bit.

I think there are two takeaways from this: ServiceNow was designed as a platform first, and the market only bit on the vision after Fred and team layered pre-canned applications (products) on top. The product just happened to be ITSM, because that’s what Fred knew from Peregrine, and the market was ripe for innovation in this space.

If you’ve seen Fred speak about his original vision for the platform, you know it came out of his desire to have a tool that could easily re-create form-based processes. Why do something on a paper form if it could easily be re-created in a computer based- system? So the platform was designed around this concept – the rapid development of form-based applications. This included the following elements:

• The ability to create new tables in the database
• A set of database field types that have inherent UI functionality (e.g. Reference and Journal fields)
• Inherent UI elements on top of (almost) any database table
• The ability to extend existing database table and inherit not only the data elements, but the UI and flow elements as well (as needed)
• The ability to create and run graphical workflows against (almost) any database table
• The ability to send and receive email notifications against (almost) any database table
• Graphical and script-based configuration elements that let you manage the UI to business process needs
• Server-side script-based business logic elements
• Graphical and script-based security configuration

The real key in this is the inherent elements that were “baked” into every table in the database, even those created by customer admins. If you create a new table, you automatically get default form and list views of that table’s data, and the ability to add or layer any of the other listed aspects to it. So customers could quickly spin-up new applications by creating tables and configuring how it is presented in form, lists and reports, and layer in business logic as desired.

Similarly, the original developers simply used these platform elements – that any ServiceNow platform administrator can access – to create a set of ITSM applications. In the 15+ years since, ServiceNow development has continued to use these elements to build other application sets: Customer Service, Human Resources, IT Operations Management, etc. But what hasn’t changed is the platform under these applications.

All of this is to say that the real power of ServiceNow is the platform, not the applications that sit on top of it. I realize that the average ServiceNow admin and/or developer doesn’t have the insight into the history, standards, business processes and other elements of every application and application suite in the platform. (For example, I have very little knowledge of all the reasons HR Management is built the way it’s built.) So there’s value to having knowledge and expertise behind the creation of a particular business application. However – and this is where the curmudgeon in me emerges – what has happened in recent years – really since Fred stepped back and stepped down from the company – is ServiceNow has tilted its marketing focus from being a platform company that happened to do ITSM, to being a product company that happens to run on a flexible platform. I doubt this shift was fully intentional or fully clean; rather, it’s been a gradual shift based on several factors:

1. Changes in company leadership: ServiceNow is now on its fourth CEO, along with the requisite management changes that happen along with it. Each change brings in leadership with their own histories and biases, without the knowledge of the platform’s history.
2. Responding to market feedback: I’ve heard from C-level ServiceNow folks that the platform direction is at least partially dictated by conversations had with customer C-level folks. These are conversations that rarely focus on underlying technology but rather broad business needs, particularly financial in nature. There’s a reason “stick to out of the box” became a thing, and this is a big part of it.
3. Aligning to shareholder needs: Going public means the company is driven by quarterly and annual financial results moreso than innovation. You can draw a straight line from the ServiceNow product releases of recent years – and their accompanying licensing – to quarterly financial goals that edify the markets. (For a great read on what this mentality does to companies, see Christensen’s “The Innovator’s Dilemma”, ISBN: 978-0062060242.) It’s easy to draw a straight line from Importance of Financials to Licensing to Focus on Product and not Platform. You can’t easily sell Platform improvements, but you can easily sell and market new Products.

You can’t necessarily argue with the results. (Check the share price.) My concern is that like a lot of successful companies that lose sight of what made them great, the turn from Platform to Product will catch up with them sooner or later. It’s a testament to how great the core platform is that the success continues, but as the complexity of the Products ServiceNow builds on top of it continues to increase, and admins and developers are hamstrung by the need to stay out of the box – rather than adopting the platform to their business needs – one wonders how much Platform goodwill will erode over time.

Last note: I’ve been saying for years now that it feels incongruous every time I attend a Knowledge conference and hear, “Upgrade-proof your instance – Stay out of the box!” in one ear and eye, and in the other, “CreatorCon! Create anything on ServiceNow!”. This incongruity goes hand in hand with what I’ve outlined in this article. Ultimately, I still love the platform but struggle to love its products.

(I’ll have more about “out of the box” and “upgrade proofing” in other articles.)

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.