Often times when reviewing their upgrade history, customers will notice records that were skipped during the upgrade. This tends to start the waterfall of questions around why the upgrade to a specific Out-of-the-Box (OOTB) record was skipped.
Generally speaking, upgrades skip records because a previous version of that OOTB record was customized and the record is no longer OOTB. A record of this customization gets recorded within the Customer Updates table, sys_update_xml. The easiest way to determine if a custom record exists for the skipped record update is to pull the file name for the record from the upgrade history record.
How to determine if a custom record exists for this case:
First, pull the file name for the record from the upgrade history record.
Next, search for it in the 'name' field within sys_update_xml.
Once you have located the record you can then choose one of three options:
- Keep the record and have your customization remain, but not get the new OOTB update.
- Manually merge the new update into your existing customization, creating a new better one.
- Revert the record to OOTB from the upgrade history by right-clicking on the record row and choosing 'Revert to Out-of-box' ('Revert to Base System' in Geneva):
It is also good to note that certain updates made to OOTB records, while producing Customer Update records, will not prevent the record from being skipped on upgrade, and some updates do not produce a Customer Update record at all. To understand the reasons behind both of these caveats, lets look at them in additional detail by reviewing the following scenarios:
I deactivated an OOTB record, will this prevent the record from being updated?
No. When simply changing the Active Flag on an OOTB record from TRUE to FALSE (or vice versa), a Customer Update record will be created, however the Replace-on-Upgrade flag for the record will be set to TRUE, meaning that the record will still be upgraded during upgrades, but the record will not be reactivated. In short, the record will get upgraded, but it will still be inactive.
I removed an attribute on an OOTB sys_dictionary record, and it was replaced on upgrade, why?
The way that attributes are treated by the upgrade is different than other elements within a record, as updates to attributes are not recorded within the Customer Updates table. During an upgrade the process simply looks to see if the attribute is present or not. IF present on the OOTB sys_dictionary collection record, even if customized, it will not update the attribute or replace it with the OOTB version. If however you have removed the attribute from the sys_dictionary record, the upgrade will re-add the OOTB attribute to the sys_dictionary collection record because it is 'missing'.
I made a customization to an OOTB record but it was not recorded in Customer Updates and the customization was returned to OOTB upon upgrade, why?
Customer Update records are only created for those tables that have the update_synch=true attribute OOTB, not only is this attribute required for the creation of Customer Update records but also for the capturing of customer updates within Update Sets, without it updates to records will not be recorded. This is rare however, as ServiceNow does not typically update records in tables where update_synch is not true.
PLEASE NOTE:Do not add the update_synch attribute to a dictionary record. When improperly used, this attribute can cause major performance issues or cause the instance to become unavailable. Adding this attribute is not supported.
Geneva Update:
A new feature was included within the Geneva release that allows you to capture your revert to out-of-box actions in an update set, and move these choices to each instance, post-upgrade to Geneva. In this way you will only need to review the skipped records once on your first Geneva upgrade, decide which items to revert to out-of-box, revert them, and then commit your 'revert' update set to each instance instead of needing to track and manually repeat all of your reverts on each subsequent upgrade.
17 Comments
