As an administrator of a ServiceNow instance, you probably have to deal with a version upgrade once in a while. Most of the times this is a smooth procedure and your users are up and running without even noticing that anything has happened.
And then there are those other times.
I'm referring to when a basic functionality suddenly starts misbehaving or stops working completely, even if you have tested, evaluated, and debugged all possible scenarios that you and your team could come up with. In this blog I will address a module that is commonly affected by upgrades: Service Catalog.
A recurring example of post-upgrade issues: the Service Catalog
One of the modules we see most affected by upgrades is the Service Catalog. This seems logical as it's the most used application by end users, and by far the most customized by our customers. And this last statement is what I want to write about here.
By default the ServiceNow platform does not overwrite customizations when upgrading. We don't want you to lose your own enhancements; you have made them for a purpose and you should be able to keep using them. This, however, is a double-edged sword. Occasionally an upgrade brings bug fixes, changes in functionality, and other enhancements that can unintentionally break your existing functionality simply because a scripted object (think Script Includes, UI Scripts, UI Macros, etc.) has been refactored or rewritten is such a way that your custom code does not work anymore.
In these cases, the first place to look at is the Skipped Updates in your Upgrade Monitor (System Diagnostics > Upgrade Monitor). In the most recent versions of ServiceNow you will see a widget similar to the following image, which shows the number of records that were skipped during the last upgrade, and a link to the list.
The details on how to proceed with skipped records are detailed in the documentation: Resolve a skipped update. When you access the related list with Skipped Changes to Review you will see that there are different types of records that you can review, and for text fields you can open a side-by-side diff view so you can easily merge some changes into your customization.
For each of the records you can choose to apply the following options:
- Retain the customization with no changes
- Retain the customization by merging changes from the updated object
- Overwrite the customization by reverting the customized object to the updated system default version
- Review the skip and perform no action on the object
There is also a knowledge article dedicated to the specific case of the Service Catalog: Service Catalog shopping cart variables and order guide issues after upgrade (KB0639132).
You should be able to filter the skipped records to find any scripted object that could be related to the Service Catalog. The examples provided in the mentioned KB article are a good start, especially the filter on the Plugin field, to retrieve records related to the catalog.
Often you will be able to restore functionality by reverting a customized script to the new out-of-box version that pertains to your new version. Even if this does not recover your custom functionality, it will provide a working version of the catalog until you can update and test your customizations. You might want to have a look at this other blog post on how to Easily debug catalog customizations in Jakarta.
For more information on managing skipped updates after an upgrade:
4 Comments
