ServiceNow reviewing skipped objects when upgrading an application

 goto:

sys_upgrade_history_log_list.do

As this is a large table to query, if you know the application name enter in this format - in this case the plugin namespace is x_cls_clear_skye_i  which gives me something to filter on:

sys_upgrade_history_log_list.do?sysparm_query=pluginSTARTSWITHx_cls_clear_skye_i%5EdispositionIN4%2C104%2C9%2C10%5Echanged%3Dtrue%5EORdisposition%3D9%5Eresolution_status%3Dnot_reviewed%5EORresolution_status%3D&sysparm_first_row=1&sysparm_view=

review ServiceNow's guide, What’s the process to review and address skipped changes?

• Group skipped updates by table or type to quickly review records.
  
• By focusing on a single record type, patterns emerge and commonalities can be established.
• The same action may be desired for many skipped updates of the same type.
• Filter irrelevant records easily 

• For each legitimate skipped update, compare differences and determine if it should be:
  
  • Retained
    
    • All customizations are retained.
  • Reverted
    
    • The customized record is replaced with the out of box version.
  • Merged
    
    • Some customizations are retained and others reverted.
• Capture changes in update sets as appropriate.
• Document potentially impactful decisions or affected areas as targets for additional testing and validation.
• While the Upgrade Details table is a great resource it can be difficult to work with and sometimes provide unhelpful or confusing results.

Navigation

Typical navigation to skipped updates is to follow System Diagnostics > Upgrade History from the Application Navigator, then search for System Upgrades where To > contains > "clear", then opening the upgrade record.

Working within the "Skipped Changes to Review" tab can be cumbersome as sorting and filtering options are limited and a portion of the screen is consumed by the System Upgrade record. Instead, use the below-provided URL (example), replacing the desired instance name where specified.

 

https://[your instance].service-now.com/sys_upgrade_history_log_list.do?sysparm_query=pluginSTARTSWITHx_cls_clear_skye_i%5EdispositionIN4%2C104%2C9%2C10%5Echanged%3Dtrue%5EORdisposition%3D9%5Eresolution_status%3Dnot_reviewed%5EORresolution_status%3D&sysparm_first_row=1&sysparm_view=

The filter is designed to provide the same results as shown on the Skipped Changes to Review tab.

 

False Positives

 

After upgrading the application it is not uncommon to see skipped record entries in the hundreds. In our experience, many of the skipped updates are in fact, "false positives". In this case, the term "false positive" refers to a skipped update record which doesn't resolve to any actionable configuration change.

 

Although it's impossible to predict whether an actual customization has been made and therefor should be reviewed, the following types have been found to generate many false positives and can be ignored with caution:

 

• Choice List (sys_choice)
• Flow Variables
• IGA Scheduled Script Execution

 

for example of a Choice List false positive update record.

Typically, the Resolve Conflicts action results in a form comparing original and customized values. For many Choice List (sys_choice) entries, for example, users will instead encounter a message, "Enable to compare, unable to find a current record". This behavior has been observed in instances which have not been customized, confirming the "false positive" nature of the skipped update. As there's no action to perform, this record can be ignored.

Error message resulting from Resolve Conflicts UI Action.

 

Additionally, skipped updates related to the following types are often customisations based on customer needs and would be impactful to users if reversion to occur without organisational change management communication.

• List Layout (sys_ui_list)
• Form Layout (sys_ui_section)
• Related Lists (sys_ui_related_list)
• UI View (sys_ui_view)

 

A note on update sets

 

When making changes to [your scoped app] as part of an upgrade (reverting customisations, making configuration changes, etc.), the vast majority of changes will take place to records within the app scope. However, when resolving skipped updates in app scope (and other scoped applications) a NowPlatform bug captures a change to the "Resolution" field within the skipped update record (sys_upgrade_history), which is in the Global scope. Because this Global scope update is captured in the current update set (created in the application scope), when attempting to promote this update set, users will receive the message, "Cannot commit Update Set because "Update scope id is different than update set scope id "global'. Resolve the problem before committing."

 

The recommended workaround for this behaviour is to remove any Upgrade Details entries within the application scope update sets.

Workflows

 

The ability to compare previous and current configurations via the Resolve Conflicts action (as shown above), is not effective for Workflow entries. Instead, use this list to determine which workflows may have been customised. Then, compare the conditions, workflow activities, scripts and configurations to those of found in the application out of box (knowledge base article coming soon).