Hi there,
With the Vancouver release ServiceNow introduced "Skipped Record Rules" within Upgrade Center. It appears to be a very useful addition when working on Skipped Updates after Hot fixes/Patches/Upgrades. Since Skipped Record Rules didn't get much love and attention yet from the ServiceNow eco-system, let's dive into it!
Skipped Updates
Handling Skipped Updates after Hot fixes/Patches/Upgrades, isn't that everyone's favorite... Oke probably not 😅. On larger/older Instances or Instances which lack proper governance the number of Skipped Updates will run every release in the hundreds or even thousands. In theory it is desired to handle ALL of them, which can be a time-consuming task and not every ServiceNow administrator or developer is capable of performing this task. This is where Skipped Record Rules might assist you a little bit.
First a small throwback on what Skipped Updates are, here's one of the explanations that can be found from ServiceNow:
"A skipped change is a record that gets created when you have made a change (i.e., a configuration or customization) to your Now Platform® instance and ServiceNow® updates the same records as part of a new release (e.g., from Orlando to Paris). ServiceNow upgrades will not overwrite changes you have made, so you will need to review your skipped changes and determine whether to revert to base, merge, or keep your changes. Review release notes prior to upgrading to identify enhancements that may generate skipped changes in your instance(s)."
Do note that skipped changes will also occur for records that you are not aware of having changed, though for whatever reason are seen as customer updated.
When viewing the Upgrade Monitor within Upgrade Center (Upgrade Center > Upgrade Monitor, or upgrade_monitor.do), within section "Skipped records from upgrade to *" there's an overview of the Skipped records for the last Hot fix/Patch/Upgrade. It might look similar like this:
Since the Vancouver release, on the bottom left there's a new link visible that refers to Skipped Record Rules.
Skipped Record Rules
With the Vancouver release ServiceNow introduced Skipped Record Rules within Upgrade Center. Skipped Record Rules are described by ServiceNow as: "Create skipped record rules based on your set conditions to define your customizations after an upgrade."
After a Hot fix/Patch/Release Skipped Record Rules are automatically executed. If there are any Skipped Records matching the conditions of one of the Skipped Record Rules, those Skipped Records will be handled according to the conditions defined on the Skipped Record Rules. Skipped Record Rules can automatically update the Action and add a Comment.
Out-of-the-box ServiceNow has added four inactive Skipped Record Rules. Skipped Record Rules are stored in table "sys_upgrade_skipped_record_rule". Here is an example of one of the out-of-the-box Skipped Record Rules:
Create a Skipped Record Rule
Creating Skipped Record Rules isn't that complicated, or it doesn't have to be as shown in the first example below. On this example, some of the more frequently updated System Properties during Releases have been listed. For several of my customers, I've experienced that these System Properties would be handled almost every release again, and with the same action. A nice example for which you can create a Skipped Record Rule.
The available actions are:
- Keep My Modifications
- Revert and Keep Inactive
- Assign Skipped Records to User
- Assign Tags to Skipped Records
It is possible to make more complicated Skipped Record Rules. When Upgrading it is very common to have Skipped Records for Notifications, Notifications that have been deactivated on purpose on the customers Instance. Spending time reviewing and acting on such Skipped Records is a waste, so let's create Skipped Record Rules! While the no-code options on the conditions are limited, we can use code. Below is an example of applying logic defined in a Client Callable Script Include. Logic which would get all inactive Notifications, so that Skipped Record Rule would automatically handle Skipped Records for inactive Notifications on the customer Instance.
Client Callable Script Include:
var UpgradeMonitorUtilAjax = Class.create();
UpgradeMonitorUtilAjax.prototype = Object.extendsObject(AbstractAjaxProcessor, {
getListDeactivatedNotifications: function() {
var TableName = 'sysevent_mail_action',
EncodedQuery = 'active=false^sys_updated_by!=admin^sys_updated_by!=fred.luddy';
var grRecord = new GlideRecord(TableName);
grRecord.addEncodedQuery(EncodedQuery);
grRecord._query();
var recordArr = [];
while(grRecord._next()) {
recordArr.push(TableName + '_' + grRecord.getUniqueValue());
}
return recordArr;
},
});Of course this is an example! Don't simply copy/paste, decide if such is applicable and appropriate to apply on your Instance.
Execute a skipped record rule
I thought the first time Skipped Record Rules could be applied and tested, would be at a next Hot fix/Patch/Upgrade. Luckily though, that's not true... I missed this part at first 😀. It is possible to execute a Skipped Record Rule manually! When viewing the list of Skipped Record Rules (so not a viewing a specific Skipped Record Rule), one of the available actions is "Run Now".
Skipped Record Rules History
There is also a good overview of the history behind Skipped Record Rules. This is visible in table "sys_skipped_record_rule_history".
Result
With Skipped Record Rules in place, after a Hot fix/Patch/Upgrade hopefully the Upgrade Monitor in Upgrade Center immediately shows that a part of the Skipped records were handled automatically. For one of my customers, upgrading to Washington DC Patch 0 we did achieve to automatically handled 55 out of the 91 Skipped Updates!
---
That's it. Hope you like it. If any questions or remarks, let me know!
| 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
9x ServiceNow MVP
---
Hello Mark,
Great article as always.
QQ: I created a rule to test one Notification as below however system shows no record exists that match condition when there is one. What am I missing here ?
