Introduction

Unless you’re brand new to the ServiceNow ecosystem or have completely ignored all talk and literature about the platform in recent years, you’ve heard the drumbeat of a couple of key messages (that I’ll paraphrase):

1. Low and no code solutions are the future
2. Stay “Out of the Box” as much as possible

Out of the gate, the question I’ll pose is: does low code / no code matter? If so, why does it matter? In this article, I’m going to present an analysis of when to and when not to code, for the ease of build and maintenance of your ServiceNow platform. And – spoiler alert – the answer is not as simple as “code is bad, low/no code is good”.

Low code and no code solutions are some of the buzziest IT terms in recent years.  I suppose the idea behind these is that non-coders can “develop” solutions on a platform without having to write lines of code. (In reality, the platform is giving them a GUI that writes the code for them behind the scenes.)  I’m not going to delve into whether I think this is a good idea – I’ve already covered many of the arguments in a previous article. Instead, I’m going to go into the decision-making process for those who can code: when should you code, when should you avoid coding, and what is the correct balance. And of course this is all with the context of ServiceNow.

The article presupposes that almost every ServiceNow “shop” – an organization’s ServiceNow staff – has admins and/or developers that know how to write code* working on their implementations. I have not found many companies that do not – at the very least they have a partner or contractors who do. At the same time, I have also found that many folks implementing on ServiceNow, particularly those with a software development background, tend to overcode their solutions. In other words, they tend to write code until the requirement is met or the problem solved. And keep writing code, and keep writing code… And the reality is that a lot of solutions can be implemented by writing code. It’s just one way the system can be made to work. (Frankly, a lot of the new ServiceNow created solutions released in the platform are overly coded. Have you ever attempted to stack trace through a ServiceNow-created implementation of a UI Action condition or an ACL that calls a Script Include? That calls another Script Include. That extends another Script Include. It’s enough to make you bang your head against the desk.)

Like most things in life, there is a happy medium to be reached. I’ll use the rest of this article to elucidate some strategies and examples for how to achieve a balance, and hopefully get you thinking. (For recommendations on how to create code once, configure often solutions, see this article where I delve into specific examples.)

When Not to Code

• When a ServiceNow UI element will do the same thing:
  • Using a condition builder instead of a condition code string
  • Using a UI Policy instead of a Client Script
  • Using a simple Workflow or Flow activity instead of a large code block
• When the customer does not have developers supporting the platform, or admins who can at least manage a code-based solution
  • Of course this is case-by-case – certain custom solutions simply cannot be implemented without some coding
• When you are not prepared to create design documentation for your code-based solution
  • If you are creating a solution that implements various code elements, draw the picture of how it works together. (ServiceNow should be serving 8-10 years for a lack of this!)

When to Code

• When your company has a ServiceNow team knowledgeable in and able to support code-based solutions
  • This can be full-time employees, contractors or a long-term partner. Regardless, it implies you have people who are working on or around your platform that fundamentally understand it, and are engaged long-term.
• When building a Flow or Workflow to support the same solution will require orders of magnitude more activities, configuration and time to implement
  • This is a key one: in my experience, if you’ve got ServiceNow people who understand both configuring and developing ServiceNow, often it’s far quicker and easier to write and maintain a few lines of code than configure and test through a UI interface like Flow Designer. You don’t need to use Flow Designer just because ServiceNow says so.
• When your solution is well-documented so that future developers can easily understand how it works without having to reverse engineer your code
  • In the words of Nike, just do it.
• When the business requirement is critical or at least very beneficial and there is no other way to implement it in ServiceNow
  • The key here is there is no other way to do it, or at least not a realistic other way to do it.

An Example

There are many examples I can cite but I’ve found the most common is creating integrations. There’s been a big push to use pre-built integrations using Integration Hub or approved 3rd party apps. Like a lot of these situations, this is great if your integration requirement aligns perfectly with how the integration has been pre-built and configured. But for the purposes of illustration, let’s assume it doesn’t. (I’m smiling as I type this because I’ve yet to see one that does!)

In this situation, you have two choices:

• Create a Flow-based integration using dozens of activities and complicated logic blocks, attempting to overcome the linear nature of the tool. Potentially struggle where to configure certain parameters, and how to successfully test.
• Create an inbound or outbound REST message, write a few lines of code in a Business Rule and Script Include, and add logging for testing and debugging.

I’ve never seen a non-developer implement an integration by themselves. Not once. So given that this is highly likely to be done by a developer, the reality of this situation is that the developer is more likely to be able to review API documentation and implement through a combo of code and configuration solutions than use a UI tool that obfuscates the code but is harder to understand for the developer. And in my experience, I can develop and deploy an integration a minimum of 3x faster by avoiding using a no-code solution.

Conclusion

A common thread through many of the articles I write is “don’t believe the hype”. This is no exception. As non-technical and unscientific people breathlessly espouse the tremendous benefits of low and no-code solutions, and citizen development, I constantly weigh this against what I see and experience “in real life”. And what I see and experience does not align with the marketing pitch.

Conversely, I also see over-coded solutions all the time, not the least of which is ServiceNow’s own out-of-the-box solutions. And I’m most definitely not espousing these either. As with many things in ServiceNow, this balance is as much art as it is science. I simply can’t give you a definitive list or decision matrix when to code and not to code. It takes knowledge, intelligence and experience. But hopefully I’ve given you some ways to think about it.

Happy developing!

*specifically writing Javascript and using the ServiceNow Glide APIs

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!

Application scoping protects applications by identifying and restricting access to application files and data. By default, all custom applications have a private scope that uniquely identifies them and their associated artifacts with a namespace identifier. The application scope prevents naming conflicts and allows the contextual development environment to determine what changes, if any, are permitted.

Source: Application scope

Each ServiceNow application has an application scope that determines which of its resources are available to other parts of the system. Application scoping ensures that one application does not impact another application. You can specify what parts of the application other applications can access by setting application access settings.

Source: Understanding Application Scope on the Now Platform

The concept is that application code, configuration and data is programmatically “siloed”. This is the ServiceNow version of the old encapsulation concepts in object-oriented programming (OOP). In ServiceNow, applications across scopes have methods of interfacing with each other, but the elements that make up the application (tables, UI element, scripts, UI configuration) cannot be directly accessed by other applications unless granted specific permission to do so.

An important note: When ServiceNow moved to application scoping, all existing platform applications and elements moved into the “global” scope. This is still a scope, but with special properties – it is by its nature more accessible. In general, by default any other application can access global elements and data, rather than by default not being able to access.

Since its introduction, ServiceNow has been touting application scoping as a panacea to many development ills. The stated “best practice” is to always build new applications inside of a scope, and if you’re familiar with installing new applications from plugins or the ServiceNow store, you’ve likely seen quite a few scopes added to your platform environments. For example, in my Personal Developer Instance (PDI), which has very few plugins installed and no Store apps, I have 115 primary application scopes. (The main thing I’ve installed outside of the baseline platform is Customer Service Management.) To me, ServiceNow has gotten “scope crazy”. For example, in my PDI, just within the Change Application there are these scopes:

• Change Management – Approval Policy
• Change Management – ATF
• Change Management – CAB Workbench
• Change Management – Change Schedule
• Change Management – Color Picker
• Change Management – REST API

I can see having Change Management within its own scope. But why are six (6) needed? Does a change approval policy need to be in its own scope? If you’ve tried to make some basic configuration changes within an application, like a reference qualifier or a dictionary override, you know what a pain it can be to have to constantly change scopes and manage all the resulting update sets.

So why has this change been made? Here are some of the stated benefits of Application scoping:

• “Containerization”: All aspects of the application are contained in a namespace
• Security: By default, parts of the platform outside of the application have limited to no access to the application
• Versioning and governance: The entire application has a version, versus the individual elements
• Deployment: Much like versioning, the entire application can be deployed and removed as an entire entity
• Isolating development: Because of the above, large development organizations can segregate development by application

Sounds wonderful, doesn’t it? I’m in total agreement with the concept. However, there are several known and stated qualifiers to developing this manner (in ServiceNow):

• If you are building an application that extends from an existing application in another scope – including global – any element you want to leverage has to be copied into your application scope. For example, if you need a Business Rule’s logic from global, you have to copy the whole Business Rule to your application scope.
• There are different platform APIs for global versus scoped applications. Many of the API calls are the same, but not all of them are. You have to be sure you are looking at the correct API documentation for your current use case.
• Managing development can get more complicated – you’ve got to pick the correct application in addition to the correct update set. This gets more complicated if you are developing across scopes.

Additionally, I’ve noted some other concern in my experience working with this functionality:

• By isolating development, there is a human nature aspect to consider – that developers are less likely to consider platform architecture when developing. There may be a comfort level with the siloing which might lead development organizations to skip oversight of design and standards.
• Having to develop so that applications can use cross-scope APIs and elements adds a non-trivial amount of overhead to development times. In my experience, I’ve noticed a 20-25% uptick in time to develop inside of non-global applications. This is not an across-the-board universal uptick; rather, most things take the same amount of time, and once in a while something that would take 5 minutes in the global scope takes 2 hours in the application scope, as you scratch your head and desperately search why something that works quickly and easily in global doesn’t work at all in your application scope. So there is a large uptick in time on a small number of elements that averages to a 25% total time increase over the course of a development project.
• Pushing upgrade sets across environments using multiple application scopes causes more conflicts and errors than just using global.

My conjecture is that had ServiceNow been designed with scoping from day 1, these probably would not even be concerns – it would have been worked out and eliminated in the platform design process. Instead, scoping has been bolted on “after the fact”, and it raised these and other concerns I’m probably forgetting.

I’ve thought a lot about the question of whether to scope or not to scope. I get asked about it all the time on projects that require custom applications. In my experience, these are the actual reasons to use an application scope:

1. You are building something you want to package to put on the ServiceNow Store or Share site, outside of your ServiceNow environment(s).
2. You save money on licensing.
3. You aren’t versed enough in the platform to feel comfortable implementing isolation techniques in the global scope, such as ACLs, or you aren’t comfortable with your developers for the same reason.
4. You work in a massive development house with many teams developing in ServiceNow without any centralized management of the design, architecture and QA/QC of the platform.
5. You want to be able to say you followed ServiceNow’s advice.

What if these don’t align with your needs? My advice is that you do not need to create new application scopes in order to do custom development. Do what you’re comfortable with. I prefer the ease of developing in the global scope, and I much prefer architectural oversight of the development happening in the platform. When I consider a set of business needs, and determine custom development is required to meet them, I want to be able to determine if I should extend base functionality and use existing elements without having to deal with the issues previously mentioned with application scoping. I also want my developers thinking about how anything they’re developing affects the larger platform. I think that not scoping actually encourages and trains design and development discipline.

I’ll caveat all this by saying that I learned ServiceNow prior to application scoping, and I am comfortable managing development and updates in a single scope. If you’re not comfortable designing and developing with the whole platform in mind, by all means use the tools ServiceNow has provided. I’m not saying it’s a bad thing, I’m simply saying that I don’t think it’s necessary and can have negative side effects. As always, think before you act

Happy developing!

Over the years I’ve seen this flexibility used in a myriad of ways, some really clever and some head-scratchers. Most fall somewhere in the middle. It’s also been the impetus for the rise of good and best practices, from tribal hearsay to attempted codification. But one thing I feel strongly about is using the pieces of the platform in the best way possible for maintenance by non-coders. This is my good practice.

One of the elements that exists all over the platform is the ability to script your way to a solution. Often times it’s an “advanced” option on a particular element – think Business Rules and Transform Map scripts. For people with a coding background, there’s also ways to use object-oriented concepts to build classes and extensions and call them from most anywhere you need them. What we’ve seen in recent years is ServiceNow itself has moved into this for much of its new product development. Anywhere advanced logic is needed – something that requires logic that can’t be contained in a single core element – ServiceNow development is building advanced, decomposed scripts (usually in standalone Script Includes) and calling them from script blocks in platform elements: ACLs, Business Rules, UI Actions, etc. The issue with this is it requires a coding background to either understand the logic flow, or to make changes required for your business.

(I’m going to go on a slight rant here. If you don’t care to read my angst and just want my good practice suggestion, skip to the next paragraph.) In my opinion, this is simply poor design and is indicative of turning ServiceNow over to coders and not critical thinkers. The founders of ServiceNow gave us all the elements we needed to create code-light solutions but they aren’t being used. I often say to customers, “you can code your way to anything, but this isn’t good design”, but I also see a lot of customers whose admins or outside contractors working on their instances just write code until a problem is solved. Great. So now any troubleshooting or changes require going through mountains of code to try and solve. This is not a sustainable maintenance model and should concern anyone making budget decisions about paying for ServiceNow development and maintenance.

So what am I getting at with this article? What I’m suggesting is that if one is smart with designing solutions, these solutions can be maintained through configuration and not code. The solution looks something like this:

In this scenario, the UI Element is out of the box, and the code and config are created by the developer. What’s important to note is that the code is written once, as part of the development of the solution, and changes to the logic are done through the configuration. In other words, the code is simply a mechanism to connect the business logic to the front end, and the logic is contained in configuration.

Let me go through a more specific example of this. I’ve worked with quite a few customers who are using Customer Service Management (CSM) and ITSM and need them to work together. From a business logic standpoint, CSM Cases need to integrate to ITSM records (Incident, Change, Service Request) when non-CSM teams are needed to solve an issue or fulfill a request in order to complete a Case. The Case remains the purview of the customer and the CSM Agent teams, but backend teams and processes are needed to “finish the job”. I call this a Process Integration or intra-ServiceNow integration – it works much the same as a ServiceNow to other system integration (or SN instance A to SN instance B), but is managed wholly within a single instance and works to integrate disparate records and processes rather than systems.

ServiceNow has recognized this need and created a Service Management integration plugin (check name), but this solution is all code, 100%, down to the field level. If you need your process integration to work any differently than what ServiceNow has provided, you have to write your own code to make it work.

To me, this is clearly not ideal. So what I’ve done is something that looks like this:

The key is that we use mapping records to maintain what should go where, when.  The code simply is middleware between the maps and the application – it is kicked off when needed by the application, does lookups against the maps and updates records accordingly. The map records tells the system the following:

• What record and field to pull from
• What record and field to push to
• When the transaction should occur*
• Any field value translations required

* If you’re really slick, you use condition builders on the map records to determine the when. For example, you may only update the Case State to resolved when the integrated Request completes. Rather than building lots of Business Rules or writing If/Elses into your code, you build it into the mapping record. Now customer admins and even “admin-lites” can maintain business logic in configuration records and not code!

The elements described above can be extended and used for any Task integrations required across the platform. The steps are:

• Create Task Mappings as required
• Create Business Rules on the source tables – I usually just add a condition that the source record has to have a related Task-type record – that call the Script Include and pass the source and destination information to them.

I don’t consider any of this out of left field. Why? ServiceNow has already provided a model for this type of solution: Transform maps. While they were designed for importing data into the system, the use case is the same: We need to get data from one place to another, and we need allow for transformation of that data and logic to say when the data should be inserted, updated, or ignored. So why not use the same model for a process integration? 

I’ve described a specific use case, but if you’re thinking along with me, you realize this way of thinking can be used for other development scenarios. For example, I’ve seen quite a few consultants and customers (including myself) develop Service Request fulfillment lookup tables for Approvals, Tasking, routing and other data points. The goal is not to have to maintain dozens or hundreds of workflows (flows) or to have to checkout and edit a workflow every time a simple configuration change is needed. Ultimately, the lesson is this: when you’re designing a solution to a business problem in ServiceNow, always think, “Can I build this in a way that a non-coder can maintain the solution? Does it have to be solved with code only?” I suggest the answer to the latter is rarely “yes”.

Happy designing!

In recent years in the ServiceNow ecosystem, one of the topics that has taken on a “blob-like” existence is upgradeability: the ability to perform an upgrade to the next ServiceNow release, how long it takes, how much it costs, how much remediation is required, and to minimize all these aspects. I’d posit this is directly related to the increasing costs of the platform, and the ensuing exposure to C-level organizational people, and in particular, those who control the corporate purse strings. In conjunction with this, catchphrases such as “How to make your instance upgrade-proof” and “Stay out of the box (to make upgrades easier)” have taken on an inflated importance in companies’ ServiceNow journey. 

For this article, I’d like offer my opinions on the following topics, based on my experiences of 11 years of dealing with this:

• What actually affects your upgrades? What does it mean to take ownership of a ServiceNow element and go away from “out of the box”? What does it mean for your upgrades?
• How do you configure, design, develop and customize in ways that upgrade-proof your instance? 

How Upgrades Work

First, let’s talk about how an upgrade really works. ServiceNow releases a new version of the platform, which includes “black box” items and new items stored in the database. We don’t care about the first (and can’t even if we wanted to). The new database-stored items* are what cause us potential work. There’s three (3) scenarios when ServiceNow attempts to push these items with the upgrade:

1. A net new item is inserted into your instances. No conflicts occur because it is brand new, not seen in previous versions of the platform.
2. An existing item has a new version that updates your instance. You have never touched the item, so it upgrades with no issues.
3. An existing item has a new version that attempts to update your instance, but the existing item has been “touched” by you, so the upgrade skips the update, and you are left to research the differences and determine what to do. This is where the real upgrade work occurs.

* ”Items”: The ServiceNow configuration elements we are familiar with: Business Rules, UI Actions, Policies, Scripts, etc., that live inside of the ServiceNow database

So how does ServiceNow determine what should be skipped? If you’ve worked in ServiceNow for a while, you’re probably familiar with the “sys_update_xml” (“Customer Updates”) table. This is where every configuration or customization you’ve done is captured – the record of every Update Set entry. Without going into detail, any database table in ServiceNow that contains the metadata items that make up the system configuration is marked, and the system adds an entry to the sys_update_xml when any record in these tables is created, updated or deleted. If you update or delete a metadata item (record) that ServiceNow provided “out of the box”, it’s in sys_update_xml and you now “own” it. If you’re following the logic, the ServiceNow upgrade checks sys_update_xml when it attempts to update the metadata items. If it finds an entry in this table, it skips the update. (This includes marking a record inactive! I don’t know how the urban legend began that unchecking “Active” is upgrade-safe, but it’s not.)

I’ve include a screenshot representation of this here:

What this means is you’ve now got a skip log entry, and if you’re doing your due diligence, you check why and determine if and how to remediate. When something is skipped, it is advisable to review and understand what might have been lost in the skip. But it may not be required – “losing out” on new functionality doesn’t mean the system isn’t going to work! 

The other type of upgrade diligence is regression testing your current functionality to make sure nothing broke. This is particularly important for configuration changes and customizations you have made. When something breaks, it could be as a result of a skip. Usually this is a process break rather than an obvious UI issue or system error. For example, a new or change to a Business Rule is conflicting with a new Business Rule ServiceNow provided and causing logic issues within an Application lifecycle flow, rather than an ominous pop-up error message.

Upgrade Proofing Your Work

The previous section is very tactical in nature – what happened, what happens, and what to do about it. Now I’d like to discuss some ways of thinking about your work on the platform that might ease your upgrade processes. We’ll call it “Strategic Design for Easy Upgrades”. 

When you have to develop something on the platform, first consider the Business Requirements being presented. Think about what ServiceNow has provided Application-wise “Out of the Box”, and see how your company’s requirements align with them. Consider particularly:

• Does the lifecycle of the use case align with the out of box application? 
• Does the use case have special security requirements?
• Does the use case have special data schema requirements for a single entity (record)?
• Does the use case need special notifications?
• Do end users need the ability to save something as a “draft” before submitting?
• Do the reporting requirements align with the data schema?

When the business requirements don’t align with any out of the box application or function*:

• First consider an out of the box application with adjunct functionality
• Then consider a custom application
  * and the business requirement isn’t flexible

When I say “adjunct functionality”, what I mean is new functionality that runs in parallel with the “out of the box” functionality, not as a replacement or a customization to an existing item. For example, a brand new email notification with a different set of conditions and different content, or a new Business Rule that makes an update to a field that does not drive the application’s lifecycle flow.

I thought about some of the different development actions I’ve taken over the years and put them in the table below, categorized as “Start worrying” and “Sleep easy”, aka, “Probably shouldn’t do” and “OK to do”. In some cases there isn’t an equivalent in the “Start worrying” category, which I suppose is a good thing:

So to wrap it up, what I’m saying is if you follow the strategies from part 2 of this article, your work described in part 1 should be a lot easier. And, you don’t have to stay “Out of the Box” to do it. You simply have to understand what it means and work smartly with and around it to make your upgrades painless.

ServiceNow was designed as a platform, with a host of reusable elements. Using these for your business needs shouldn’t get you into upgrade trouble.

However… Just because you can do it, doesn’t mean you should!

Happy developing!

* – 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.