This article covers an improvement that I have found useful when reviewing skipped updates during ServiceNow upgrades. An update set is also included for others to implement on their own platforms.
ServiceNow has greatly improved the skipped update set review process since I first started using it. The addition of the Upgrade History Task table greatly helps to organize the workload and prioritization of dealing with the skipped updates. The addition of a Visual Task Board to manage these tasks make this task even easier.
I have found that there are still some processes I go through when reviewing skipped updates that are somewhat repetitive when trying to decide the disposition of a skipped update (skip, merge, or revert). In order to make that decision, I have often found that I need to track down the artifact in question and then (hopefully) review its update history so that I can determine the update sets which were applied to them. From there, I can usually trace back to a story and then determine the business case for why the customization was put in place to begin with. Unfortunately, that information is not readily available when reviewing the upgrade tasks on the visual task board.
- From the Upgrade History Task, open the Upgrade Details related link.
- From the page which opens there, you can then (usually) find the ‘Show Related Record Link’.
- From there you will be on the base editor page for the artifact in question; however, it’s update history is not always available. This means that you might need to open the record in list view and then view who last updated it.
- Alternatively, you can look up the artifact name by searching for it in the sys_update_xml table. That will usually give you who last updated it and the update set it was packaged in.
After following the above process over and over many times, I decided that it would be nice if the update history for the object was shown as related records right on the upgrade history task. I then set about creating an update set that would do just that.
The first thing I needed to do was to figure out how to relate the Upgrade History Task table to the Update Versions table. To do this, I created a relationship record called ‘All updates for an Upgrade Task’. The following screenshot shows how this record was created:
- Circled in Blue, the ‘Applies To’ table was set to the Upgrade History Task table
- Circled in Green, the ‘Queries from table’ was set to the ‘Update Versions table
- We defined the relationship between the tables using the query definition (circled in red). We query where the Update Versions ‘name’ field is equal to the parent.upgrade_detail.file_name field in the Upgrade History Task table
- Finally, a sort was added to the relationship for convenience to make the newest updates 'float' to the top.
Once the relationship was defined it was a simple matter of creating a related list on the Upgrade History Task table that used the new relationship. And finally, the related list was added to the form view on the Upgrade History Task table that is used in the Visual task board.
Below is a quick walkthrough of the review process for an Upgrade History Task now.
Below is the default Visual Task Board created during a San Diego upgrade in one of our sub-prod instances. We typically want to work from here when reviewing skipped updates.
Let's open the selected card circled below and review it.
When we open it, we get some minimal information. We can make assignments or add additional labels from here if we like. Otherwise, we are fairly limited here outside of adding comments.
We can now click on the Upgrade History Task name (circled in blue) to open the upgrade task.
After opening the task, we could open the Resolve Conflicts button below to see what is actually different between our version and the upgrade; however, this won’t tell us anything about who made those customizations or why they were made. That information could be critical to determining whether to skip, merge, or revert a skipped update.
By looking at the entire update history for the item, we can learn more about who and why the customization (or customizations) were made. The new tab added can be seen below on the Upgrade History Task record.
Below we can now view the entire history for the artifact.
- First, we can see the History item (circled in green) that was skipped in the San Diego Upgrade
- Second, we can see the previous version (circled in red) which was when the artifact was created during the Rome upgrade
- Finally, we see the current version (circled in blue). We can also see the update set name in the source field. Depending on your organization’s naming conventions, you can use this to get more information about why the customization was made and who did it. For example, in our organization, the update set naming convention is developer initials, story (or reference number), and short description. We can now go back to the story requirements with this information to see what the intent was for the customization and then use that in determining whether a merge, skip, or revert action is needed.
The updates for this effort have been captured in an update set which is attached to this article. Hopefully, others will find this useful in their own skipped update reviews for future upgrades and patches.
