Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

 

Hi there,

 

Have you ever opened an out-of-the-box Business Rule, Script Include, or System Property in ServiceNow and noticed a red or yellow warning message at the top of the form? A message like:

 

 

You might also have encountered a confirmation dialog when clicking Update. ServiceNow introduced this with the Xanadu release.

 

I had seen these warnings before, but I wanted to understand what was actually happening behind the scenes. Where does ServiceNow get these risk classifications? Which components are involved? What triggers the warnings? And how does this relate to skipped records during upgrades?

 

Time to do some digging!

 

Upgrade Impact Tracker

The Upgrade Impact Tracker helps developers and administrators identify out-of-the-box metadata that ServiceNow considers more likely to change in future releases. Or at least... that's what I think it is called 😀. The Docs refers to "Managing upgrade risk", where some of the components refer to "sn_uit" or "UpgradeImpactTracker". 

 

Why is this important? Because customizing components that ServiceNow subsequently updates can result in skipped records during an upgrade. And as anyone who has worked through a substantial upgrade knows, resolving skipped records isn't always fun.

 

ServiceNow distinguishes between High Risk and Medium Risk metadata. These classifications are based on the predicted likelihood of a metadata file being modified, using trends from recent releases. 

 

A note I would like to add: High Risk doesn't mean bad code, a security issue, or a customization that is already broken. It means ServiceNow considers that particular components more likely to change in a future release.

 

Red and yellow messages

Let's start with the most visible part of the functionality. When opening certain out-of-the-box application files, ServiceNow displays a warning at the top of the form. For High Risk an error message is shown, while for Medium Risk a warning message is shown.

 

For a non-customized file, the warning reads "Do not alter this file unless necessary". Where for customized files, the warning reads "Revert this record to Base System to reduce conflicts: See comparison".

 

Interestingly, the High Risk and Medium Risk labels are clickable. They don't open a detailed explanation of why the particular record is risky, though. Both link to the official ServiceNow documentation.

 

Messages on customized files

After modifying a risky out-of-the-box file, the warning changes. Instead of advising you not to customize it, ServiceNow now recommends reverting the record:

 

 

The "See comparison" link opens ServiceNow's existing Compare to Current interface (merge_form_current_version.do). Here, you can compare a selected version with the current version, review differences, and use the available merge or revert functionality.

 

So the warning isn't entirely static. ServiceNow distinguishes between a file that hasn't been customized and one that already has customer modifications.

 

For files without an identified High or Medium Risk classification, no warning is displayed.

 

Confirmation dialog

You may have encountered another part of the functionality. When clicking Update on a High or Medium Risk file that hasn't yet been customized, ServiceNow displays a dialog titled "File Customizations". The message warns that modifying files from their default update version can generate skipped-record conflicts. You can either Cancel or Proceed.

 

 

Bug or feature... Save or List edit

I also tried several other update methods:

• Save
• List edit

 

None of these triggered the previously shown confirmation dialog. So the dialog isn't a universal restriction. It's a preventive mechanism tied to particular update actions. And looking at the underlying components explains why.

 

Components involved

Digging into Upgrade Impact Tracker, I came across several components. Business Rules, Client Scripts, UI Actions, UI Messages, UI Page, Script Action, System Properties, Module, Script Includes, Tables. 

 

The three Script Includes involved ("sn_uit.UpgradeImpactTracker", "sn_uit.CustomizationRiskNotifier", "sn_uit.MetadataVolatilityManifestLoader") are unfortunately hidden. So we can't turn the working further inside out.

 

The three tables involved are very interesting:

• Metadata Volatility Levels [sys_metadata_volatility]
• Customized Metadata Details [sys_metadata_customization]
• Customized Metadata Risk Scores [v_metadata_customization_risk]

 

Metadata Volatility Levels

 

Labeled "Metadata Volatility Levels", this table contains ServiceNow's High and Medium Risk classifications.

 

 

I checked the table on three different instances: one running Zurich (customer), another Australia (PDI), and a Brazil (PDI) instance. All three contained 81,864 records, an interesting observation. The Docs also mentions that the table may contain metadata belonging to applications or plugins that haven't yet been installed. So this isn't simply a list of risky files currently present on your instance.

 

I found Script Action "Populate sys_metadata_volatility table" that is triggered by the system.upgraded event. This indicates to me being the components that is behind the 81,864 records on every instance.

 

Customized Metadata Details

Labeled "Customized Metadata Details", this table contains metadata customization details.

 

 

Customized Metadata Risk Scores

Labeled "Customized Metadata Risk Scores", this Virtual table contains the overlap between risky metadata and customizations. This Virtual table contains two reference fields pointing to the previously mentioned tables. The exact internal filtering and matching logic isn't exposed by these references alone, but the relationship is clear.

 

 

The ServiceNow Docs mentions that the Virtual table refreshes after a certain period or when the "Refresh" UI Action is used. What that certain period is, I haven't found. What I did notice is that the Refresh UI Action is a combination with a timestamp stored in System Property "com.glide.update.metadata.risk.last_refreshed". I would have expected a timestamp from that certain period, though looking at a customer instance... the System Property holds zero updates! Only when I opened the Virtual table manually, the System Property was updated for the first time. 

 

Disable Upgrade Impact Tracker

Knowing these components, technically you could ditch this functionality if you'd like to. Obviously, doing so: #badpractice. 

 

The idea behind this functionality makes sense: warn developers before they customize out-of-the-box metadata that ServiceNow expects to change in future releases. Though how useful is it in practice? The confirmation dialog can be bypassed simply by using Save or list editing, and the risk classifications don't explain why a particular file is considered risky. So while I appreciate the intention, I'm not entirely convinced about the practical value just yet. Perhaps there's more to discover!

---

 

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?

- Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

|

 

Kind regards,

Mark Roethof

Independent ServiceNow Consultant

11x ServiceNow MVP

---

LinkedIn