Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field
Hi there,
Almost every developer or system administrator will at some point have to deal with Skipped records. In the past, the Upgrade Detail records related to Skipped records needed to be handled manually on every instance manually.
Did you know that since the Paris release, ServiceNow made this process much easier?
It's not exactly new, but since I still notice that many customers and ServiceNow partners aren't aware of it, giving this a touch of new attention.
Let's have a closer look.
Skipped records
When upgrading the family release of your ServiceNow instance, it’s common for dozens or even hundreds of Skipped records to appear. Skipped records can also be created by patches, hotfixes, or store application updates.
One convenient place to view and manage these is the Upgrade Center.
Upgrade Details [sys_upgrade_history_log]
It's a good practice to review all Skipped records. Usually you would review all Skipped records first on a Subproduction instance. Any actions you take (like reverting a Business Rule, or merging a Script Include), are captured as Customer Updates in an Update Set.
That Update Set can then be retrieved and committed on the next instance. This way, the work you did only needs to be done once and can simply be retrieved and committed, just like any other regular development work.
Skipped records resolution tracking
In the old days, the actual Upgrade Detail records themselves would not be captured as a Customer Updates, meaning this piece of "administration" had to be handled on every single instance.
Since the Paris release ServiceNow, this process has become much simpler. When you change the Resolution field on an Upgrade Detail record, not only are the related actions (for example, reverting a Business Rule or merging a Script Include) captured in an Update Set, but the Upgrade Detail record itself is now included as well.
This behavior is triggered by the Business Rule "Add To Update Set On Resolution Change".
sys_id -> incoming_version_payload_hash
When reviewing a captured Upgrade Detail record inside an Update Set, you'll notice something interesting: the Payload field doesn't contain a sys_id. Instead, it includes a value called "incoming_version_payload_hash". This ensures that when you retrieve and commit the Update Set on the next instance, the correct Upgrade Detail record is updated, even though Upgrade Detail records have different Sys IDs across instances.
That's also why exporting/importing Upgrade Detail records manually, or forcing them into an Update Set, doesn't work: different Sys IDs.
I didn't change my Update Set when creating these screenshots... bad example 😱. Ah well, you get the idea. The Upgrade Details are captured as Customer Update, so select an Update Set before handling the Skipped records.
<edit>Below an example of an Update Set with Customer Updates regarding Upgrade Details.</edit>
---
And that's it!
Hope this smoothens everyone's Upgrade experience a tiny bit.
| C |
If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful.
Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in? |
Kind regards,
Mark Roethof
Independent ServiceNow Consultant
10x ServiceNow MVP
---
