Steps to Reproduce
- Update a record in the Default Update Set
- Revert that record to Base System (or find the sys_update_xml record for that update and set replace_on_upgrade = true)
- Modify the record again in the Default update set
A typical work pattern with Revert to Base Version automatically clears the flag on your next change to the record, because the revert is in a separate update set. The work pattern is like this:
- On dev, create an update set to track items reverted to base version
- Review your customizations after upgrading dev, including reverting to base version and merging as appropriate
- When you're done reviewing, complete that update set
- After upgrading test, apply that update set
- After upgrading prod, apply that update set
At the end of this process, all the instances have a customer update with replace_on_upgrade=true, but it's in a completed update set. If a developer edits the record, their current update set will be a different update set, and the flag will be false on the new Customer Update. It is not possible, when following this methodology, to encounter the PRB.
It's worth noting that this workaround is not necessary if adopting the Procedural Workaround methodology above.
The core problem here is the use of an update set that is long-lived. There are two ways to work around the problem on a case-by-case basis. Both involve setting up a "Revert to Base Version" update set for each scope in which you revert (for most customers, this will just be one update set in the Global scope).
Once the set is configured, simply switch to it whenever reverting, and only when reverting. Switch back to the usual update set(s) after reverting.
If you forget to switch before reverting, simply edit the Customer Update record with replace_on_upgrade=true to set its Update Set to be the "Revert to Base Version" set.
By separating your "real work" in one set -- where replace_on_upgrade is always false -- and your "Revert to Base Version" work in another set -- where replace_on_upgrade is always true -- the appropriate replace_on_upgrade flag will be considered by each subsequent upgrade. Because the upgrade engine considers the sys_update_xml with the most recent sys_recorded_at, and no developer ever updates a sys_update_xml record that already has replace_on_upgrade set to an undesired value, you will not experience unexpected customization overwrites on upgrade.
Related Problem: PRB1239377