Revert customised record to OOB and transfer via Update-set for UpgradeabilitySummaryUpdate sets can track customizations to application tables, fields, and records. Instance Customization FAQ and Guidelines Any customisation will create entries on 2 tables. sys_update_version ==> which maintains 1 record each for each save and also the OOB record which comes via Upgrade.sys_update_xml ==> If you have an In progress update-set, only the latest record from the last SAVE will be stored there linked to that update-set. Committing an update set from another instance will also create an entry on sys_update_xml Some records are tacked by table_name_sysid Some records are tracked by sys_*_table_name_field_name. These are records where Coalesce strategies determine comparison If you close the current In progress update-set; any changes you make will be stored on a different update-set and sys_uopdate_xml will have only 1 entry per update-set for a given sys_id.This can be a current Custom/Default update-set. So if you make 5 changes and SAVE 5 times, there will be 5 records on the sys_update_version table for that sys_id linked to that update-set which was In progress while it was saved There will be 1 record each on sys_update_xml for respective update-set During an upgrade, Upgrade Engine will only look for customisations tracked on the sys_update_xml table The field is "Replace on Upgrade" on the sys_update_xml tableIf the "replace on upgrade" is "false" the upgrade engine will not touch the customisationif the replace on upgrade field is "true" the upgrade engine will overwrite the customisation( if there are multiple entries; the value on the latest entry will be taken into consideration) Any entry created on sys_update_xml will be made with Replace on Upgrade as the default value "false" So if your organisation are in the process of cleansing the customisation back to OOB for Upgradability 1. Identify the configuration ( sys_script, sys_ui_action..sys_*…etc) which needs to be made OOB2. Identify the scope of the record by going to table_name.list. This is in the field "Application" 3. Open a new update-set and make it current on the same Scope of the record to be modified3. Go to sys_update_version table and search for the name containing the sys_id of the record to be modified/table_name_field_name ( in case of Coalesce strategies)4. Locate the OOB record and open it and select the UI Action on the form " Revert to this version" 5. This will create an entry on the In Progress Update set on Point 3 with an entry with "Replace on Upgrade" as "true"6. Complete this update-set and retrieve it to TTEST/UAT7. This update-set can be committed to any instance and the value of “Replace on Upgrade” will remain as "true".This will make sure that the record stays OOB and will be upgraded automatically with the next upgrade. Screenshots from my OOB instance are attached.I took an example of a sys_ui_action. More information on Overwrite customizations during an upgrade How to ensure workarounds applied are overwritten with fixed OOB records during the upgrade Finding the Scope Record getting updated to OOB and getting captured on Local update-set with Replace on Upgrade as "true" On the target instance, after commit, the value on Replace on Upgrade is "true"