ServiceNow Blog

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=pluginSTARTSWITH x_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: Retain

ServiceNow modify out of the box object or work on a copy? see https://developer.servicenow.com/dev.do#!/guides/rome/now-platform/pro-dev-guide/pd-build-logic#modifying-default-behavior    In the past, one of the strategies used was to copy the artifact to update and to deactivate the original. The copy/deactivate approach is no longer recommended due to the following issues: Developers cannot tell if a deactivated artifact was upgraded without research. Two files, the original and the copy, need to be maintained. Maintenance doubles each time a customization is made. With each release, the customized record becomes older. Customers do not receive the enhancements included in a new release. A new release may rely on the original record being updated. Developers may make more changes to compensate for the original record being inactive. A script where only the  Active  flag is changed will be updated, but the script does not appear on the skipped list. With the copy and deactivate strat