The Blob is a 1958 American science fiction horror film whose storyline concerns a growing, alien amoeboid entity that comes to Earth from outer space inside a meteorite. It devours and dissolves citizens in small Pennsylvania communities as it grows larger, redder, and more aggressive each time it does so, eventually becoming larger than a building.
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:
- 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.
- An existing item has a new version that updates your instance. You have never touched the item, so it upgrades with no issues.
- 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:
| Start worrying | Sleep easy |
| Adding a new state value to an existing application | Relabeling a state label that’s conceptually the same (Closed -> Complete) |
| Changing an out of box Business Rule or Script Include | Adding a new Script Include or Business Rule script that provides adjunct functionality |
| Using DOM manipulation, JQuery or other libraries whose versions change | Scripting with any ServiceNow API calls |
| Changing out of box ACLs for specific business needs | Adding ACLs for specific business needs |
| Changing the fundamental structure or structural intention of an out of box application | Creating a custom application where out of box doesn’t meet business needs |
| Changing the fundamental lifecycle of an out of box application | Creating a custom application where out of box doesn’t meet business needs |
| Adding many fields to a table to meet a reporting requirement | Using metrics, referential data, database views and other SN elements to meet reporting requirements |
| Using “old tricks” to insert or move out of the box fields around in the dictionary | Creating your own u_ and x_ fields |
| Rearranging a form or list view to meet business needs | |
| Creating new notifications, flows, workflows, reports, database views | |
| Using platform elements to enhance the usefulness to the business |
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!
