How to resolve skipped update records after an upgrade<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Introduction After you upgrade your instance, you must review and resolve skipped update records to verify that your customizations are preserved. This process can be manual and error-prone, especially when you test upgrades in non-production instances that are clones of production. You may need to process skipped records multiple times across different instances. Skipped changes A skipped change occurs when your customization conflicts with an update in a new release. The upgrade does not overwrite your changes, so you must review each skipped record and decide whether to revert to the base version, merge, or keep your customization. Skipped changes include records such as sys_ui_form_section, sys_ui_related_list, sys_choice_set, and tables with fields of type HTML, XML, script, or script_plain. User data records, such as sys_user, do not trigger skipped changes. Process the skipped records list If you customize a record affected by the upgrade, such as a business rule or script, the system generates a skipped log record. You must process the skipped records list to resolve differences between the upgraded and customized versions. Skipped Update Records Resolution Tracking Beginning with the Paris release, Skipped Update Records Resolution Tracking allows you to capture customizations and skipped records dispositions and comments in the update set. This feature is enabled by default. The glide.save.skiplist.decision system property controls this feature and is set to true by default. Example Upgrade your source instance to the target release version.Create a local update set to capture skipped records and make it current.Process the skipped records list in the source instance.Mark the update set as complete.Upgrade your target instance to the same release version as the source instance.Retrieve the skipped records update set from the source instance.Preview and commit the update set in the target instance to apply the captured changes.The skipped error list is updated by the update set, but you must still process the skipped records list in the target instance. Details After you process the skipped records list and capture changes in the update set on the source instance, you can transfer the update set to a target instance after performing the same upgrade. The platform checks the following before applying skipped record resolutions: The glide.save.skiplist.decision property is true.Corresponding log records exist on the target instance.The same file name exists on the target instance.The sys_upgrade_state key matches the incoming version payload hash.The record changed field is true.The record resolution status is not "not_reviewed".Disposition is one of: skipped, skipped error, skipped manual merge, or retrieved.The skipped record is part of the most recent upgrade (glide.war version matches the Upgrade history column in sys_upgrade_history_log). If all checks pass, the skipped record resolution codes, comments, and customizations transfer to the target instance, saving you time after the upgrade. If any check fails, an update set error is reported. Update set warning messages When the glide.save.skiplist.decision property is false on the target instance: "This update will not result any action because Skipped Upgrade Records Resolution Tracking is disabled." The only available action is to skip the remote update. For other issues: "This update will not result any action because it is invalid and then skip the remote update." The only available action is to skip the remote update. To understand these messages, check the conditions in the section above. Additional notes If the update set contains dispositions that do not apply to the customer update, for example, if the target instance only allows Update and Delete but the update set contains Resolve Conflicts, the engine reports a warning. This indicates a difference between upgrades on the source and target instances. Review the referenced upgrade history record on the target instance to understand the differences.You cannot move or process skipped records from history logs for a plugin using an update set. Update sets only work for instance upgrades, not plugin upgrades.To reduce manual effort, system administrators can use update sets to capture customer updates from the source instance and transfer them to a target instance undergoing the same upgrade. Applying the update set on the target instance addresses skipped changes from the source, minimizing post-upgrade manual work. Related Links KB0726987 - Different number of skipped items records between instances after an upgrade KB0678054 - Upgrade FAQ - Frequently asked questions