Skipped Update Records Resolution Tracking - Upgrade related changes in Paris versionIntroduction Reviewing skipped changes after an instance upgrade is an essential part of the upgrade project. During the 'skipped changes review process' system administrators resolve the differences between the upgraded and customized versions of the record. Often this is a tedious, error-prone, manual process due to the large volume of skipped records. Considering the upgrade must be tested in a sub-production instance (which is ideally a full clone of the production instance) a system administrator must process the skipped records multiple times on different instances. In order to reduce the required manual work system administrator can utilize update sets to capture customer updates made to the instance and transfers them to another instance where the same upgrade takes place. In this way, it is enough to apply the update set on the target instance to address the skipped changes recognized in the source instance. This approach can help reduce the required manual work after the upgrade. Important changes were introduced to streamline this process in the Paris version. Skipped changes A skipped change is a record that gets created when you have made a change (i.e., a configuration or customization) to your instance and updates the same records as part of a new release. Upgrades will not overwrite changes you have made, so you will need to review your skipped changes and determine whether to revert to base, merge, or keep your changes. Skipped changes include changes such as the hard-coded records sys_ui_form_section, sys_ui_related_list, and sys_choice_set and changes to tables that have at least one field of type HTML, XML, script, or script_plain. User data records (i.e., sys_user) will not trigger a skipped change. Process the skipped records list If you have customized or altered a record affected by this upgrade, such as a business rule or script, the upgrade will generate a skipped log record. You must resolve the differences between the upgraded and customized versions of the record by processing the skipped record list, or, in other terms, just processing the skipped list. Capturing skipped records in update set - Before Paris The system tracks changes to records in an update set so you can apply these changes to another instance later. However, the system does not migrate the upgrade details records from one instance to the next. These records apply to a specific upgrade of a specific instance. If you want to preserve the Comments, Resolutions, or other information from the skipped list, export it from this instance by the export XML feature. Upgrade example - Before ParisDev instance steps. Upgrade from New York to Orlando.Create a local update set NY to O Skipped records and make it current.Process the skipped records list.Make the update set NY to O Skipped records complete.Optionally to save the skipped records dispositions, comments (for documentation purpose) export XML records from sys_upgrade_history_log table. Test instance steps. Upgrade from New York to Orlando (same upgrade source and target versions as the last upgrade on the Dev instance).Retrieve the NY to O Skipped records update set from the Dev instance.Preview and commit the NY to O Skipped records update set in order to apply the changes to the Test instance which was captured in the DEV instance.Process the skipped records list. Although by applying the update set in step 3, making the changes to the customized records, the skipped records list remains untouched. At this point, the customizations on the instance are not in sync with the content of the skipped records list.Optionally to save the skipped records dispositions, comments (for documentation purpose) export XML records from sys_upgrade_history_log table. Notes to step 4. It is very rare when two instance upgrades produce the exact same results in terms of the skipped records lists. The reason why because there is always a subtle difference between the instances, even though they are the full clone of the same production instance. The explanation in the KB0726987 KB article. A new feature is available in the Paris version called Skipped Update Records Resolution Tracking. Upgrade example - From ParisDev instance steps. Upgrade from Paris to Quebec.Create a local update set P to Q Skipped records and make it current.Please note that from Paris the glide.save.skiplist.decision system property is true by defaultProcess the skipped records list.Make the update set P to Q Skipped records complete. Test instance steps. Upgrade from Paris to Quebec (same upgrade source and target versions as the last upgrade on the Dev instance).Retrieve the P to Q Skipped records update set from the Dev instance.Preview and commit the P to Q Skipped records update set in order to apply the changes to the Test instance which was captured in the DEV instance.Please note that the skipped error list also gets updated by the update set, however it is still required to process the skipped records list. Skipped Update Records Resolution Tracking details. Skipped Update Records Resolution Tracking is a new feature introduced in the Paris version that allows you to capture not only the customizations but the skipped records dispositions comments in the update set. The feature is enabled by default from the Paris version. The glide.save.skiplist.decision system property controls this feature (it is set to true by default). Once the skipped records list processed and the changes captured in update set after the upgrade on the source instance, the update set can be transferred to a target instance. After performing the same upgrade on the target instance (using same upgrade version) the update set from the source instance can be imported and committed. In order to successfully bring the skipped record resolution codes, comments and customizations, the platform performs the following checks actions: Check the system property glide.save.skiplist.decision value, if the value of the property is true, the feature will be enabledFound the corresponding log records on the target instanceFound the same file name on the target instanceCheck whether the sys_upgrade_state key value is the same as the incoming version payload hash in the XML payloadCheck the record changed field, updates will be applied only if changed = trueCheck the record resolution status, anything but "not_reviewed" captured in the update setCheck disposition, it must be: skipped, skipped error, skipped manual merge, retrievedThe skipped record must be a part of the most recent upgrade. Check the glide.war system property. The glide.war version must match the "Upgrade history" column of the Upgrade detail [sys_upgrade_history_log] record that we are expecting to get updated (this is basically a way to check that the record belongs to the latest upgrade). If all the above conditions are true and all checks are successfully passed, the skipped record resolution codes, comments and customizations from the source instance will be transferred to the target instance. This saves the Administrator a great deal of work and time in the post upgrade process. If any of the above conditions is not true or one of the checks is not successfully passed, then an update set error will be reported. Update set warnings: If the glide.save.skiplist.decision system 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 any other situation: "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' The recommended actions to understand the reason of the message to check the above-mentioned conditions if any of them fails (2-8). Another common scenario when the update set contains dispositions that do not apply to the particular customer update. For example, in the target instance for a particular upgrade history record, the only available options are the Update and Delete. The update set from the source instance contains a customer update for the same upgrade history with a different disposition (Resolve Conflicts, for example), then the upgrade set engine will report "This update will not result any action because it is invalid and then skip the remote update" warning message. This is an indication of a difference between the upgrades. The upgrade on the source instance was different from the upgrade on the target instance in terms of skipped errors and/or customizations. A further review is recommended on the referenced upgrade history record on the target instance to address and understand the differences (compared to the source instance). NOTE: Moving or processing skipped records from history logs for a plugin is not applicable in an update set. Update set only works for instance upgrade not plugin upgrade. Related resources. KB0726987 - Different number of skipped items records between instances after an upgrade KB0678054 - Upgrade FAQ - Frequently asked questions