The Helsinki release includes the Upgrade History module that tracks every upgrade that has been made to an instance. You can use it to resolve conflicts and, thanks to a prefiltered list, review skipped updates. Use this Update Details list to determine whether you want to keep the customization or possibly revert to the base system when a handy new feature has been included in an upgrade that covers the reason you created the customization in the first place.
The Upgrade History Module Reveals All
The Upgrade History module shows you the version name of the previous .war file and the new applied .war file, and time stamps for when the upgrade process began and when it was completed. It also counts records by disposition:
- Inserted, updated, or deleted
- Skipped due to a customization
- Skipped due to an error
- Unchanged, and unchanged and customized if the component was customized but has not changed since the last release
- Total (a count of all records that were affected by the upgrade)
- Related list of every record that was affected by the upgrade (open a record to compare the base system and customized versions)
Reviewing Skipped Updates After an Upgrade
If your instance includes customizations, part of your duties as the administrator is to resolve each skipped update after an upgrade. To prevent your customizations from being overwritten during system upgrades, the upgrade process skips (does not apply the update to) objects that have been customized.
For this purpose, the Upgrade History module provides the very useful Upgrade Details related list, which displays each record that was skipped during the upgrade process. Use the list to review the reason for each skipped record in the list and then either merge your customization or revert your customization to the base system. For information on why an OOB feature was skipped, see Upgrades and their relation to customizations: Updated for Geneva.
What Does the List Look Like?
By default, the list is filtered by Disposition = Skipped and Resolution Status = Not Reviewed. The Priority value is color-coded with red for P1 and green for P5 priority. Text field differences are also color-coded: the File differences field displays a side-by-side comparison of the customization and the update version with deletions highlighted in red, additions in green, and changes in yellow.
What Can I Do With a Skipped Update?
After reviewing the changes, you can choose from the actions listed in the following table.
| Desired Action | Process |
|
Retain (keep) a customization with no changes |
Set Resolution Status to Reviewed and Retained. |
| Retain a customization by merging changes from the updated object |
|
|
Revert a customized object to the updated version (that is, overwrite the customization) |
Click Revert to Base System.
Note — Reverting a customization is not tracked in update sets. You must perform the revert procedure on each instance where you want to revert your customizations. At any time after you revert a customization, you can click Reapply Changes to reapply the customization (undo the revert). |
|
Review the skip and perform no action on the object | Set Resolution Status to Reviewed. |
Only skipped updates with a Resolution Status of "Not Reviewed" appear in the Upgrade Details related list. Any action you take that changes the Resolution Status to a value other than Not Reviewed removes the skipped update from list. If you have chosen to keep a customization and are having issues, you might want to check your variables.
12 Comments
