How to ensure resolutions applied are overwritten with fixed OOB records during upgradeSummary<!-- /*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: block; max-width: ; width: auto; height: auto; } } While a support case is open, Now Support typically will provide you with resolution guidance in the following formats: Posted as a Known error (KE) articlePosted as a Knowledge base (KB) articleUpdated as Workaround steps on a CaseThey are uploaded as XML files on a Case/KB articles for importNow Support modifying the file(s) on a non-prod instance Implementing resolutions are typically treated as customization on the instance as the above activities leave an entry on the following two tables: sys_update_version: which maintains one 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. Upgrade Engine During an upgrade, Upgrade Engine will only look for customizations tracked on the sys_update_xml table. Upgrade Engine looks for the "Replace on Upgrade" field on the sys_update_xml table. If the "Replace on Upgrade" field is "false", the upgrade engine will not touch the customization and the OOB file will be skipped.If the "Replace on Upgrade" field is "true", the upgrade engine will overwrite the customizations (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 created with "false" as the value for the "Replace on Upgrade" field. The issue arises when the upgrade to this file ( workaround) will get skipped during future upgrades as the Upgrade engine treats this as a customization. The newer version of this record may have new features introduced with the fix which will be missing on the instance. This is an expected behavior based on how the Upgrade Engine works. See Overwrite customizations during an upgrade for more information. This will also contribute to the Skipped records review after an upgrade. If you are applying a workaround linked to a Problem on a PROD instance, modify the value of "Replace on Upgrade" from "false" to "true" for that record on the corresponding sys_update_xml entry. This should be changed on the PROD instance so that this will be synched to all lower instances during a clone. Once the "Replace on Upgrade" field is updated on sys_update_xml, the version upgrade (where the OOB fix is) will overwrite the file to the fixed OOB version and you do not have to review the Skipped record and this will not be skipped on future upgrades as well. Release<!-- /*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: block; max-width: ; width: auto; height: auto; } }