"Revert to Base System" Changes Captured in Update Set, Do These "Count" as "Reverted" When Promoted to Production?

[mholmes]

My understanding is that if I address a "Skipped Change" by selecting "Revert to Base System," the record in question will no longer be considered "Customized" and will not be skipped in a future update.

Question 1: Is this correct?

Question 2: I have noticed that when I "revert" a change, this is captured in an Update Set. If I promote this Update Set to my production instance, will it be considered "Reverted" in the same way as if I reverted it "in place" in Production?

Question 3: How does the upgrade process determine if something needs to be "Skipped" or not? I found a community post that explains "An upgrade will skip every record that was ever customized/changed. If you change any field it will be flagged "Customer updated" and will be skipped. The merging does not happen in a smart way, it just checks whether the record was flagged. So imagine that you have changed a string field from "foo" to "bar" and back to "foo". The value would be the same as OOTB, but the record has been updated, so will be skipped. Therefore, you should revert instead of just changing the value back." However, I can't find anything that looks like an indicator of "Customer updated," including when I exported the record as XML. The only "interesting" thing I could see on the record was that the "sys_updated_by" field was changed to "maint."

Essentially, I'm trying to figure out if it's a good idea to push these "reversion" changes to production in update sets, or if it would be better to perform the reversions again in production directly. (I suppose I could do this semi-efficiently by filtering based on file names if necessary.) I've inherited a large number of "false positive" records that were changed and then changed back without being "reverted," and they complicate my upgrades, so I would like to put them to rest once and for all.

[shloke04 · Accepted solution]

Hi,

Please find responses for your query below:

1) Your understand is correct.

2) Yes, it is captured in an Update set once you revert it to OOB after your upgrade. My suggestion would be Upgrade your Non Prod environment first and then create an Update set. Revert the changes back to OOB as you want and capture them in an Update set.

Then deploy that Update set first which contains your reverted OOB Customization code and then upgrade your Production environment.

Should be good with no issues while upgrading your Production environment.

3) Yes your understanding is correct in reference to what you have mentioned in point 3. 

Let me know if you have any issues.

Hope this help. Please mark the answer as helpful/correct based on impact.

Regards,

Shloke

[mholmes]

Thank you! I won't be able to actually see how this shakes out for a long time, but I feel better about this approach, now.

[shloke04]

Hi,

If your query is resolved, would you mind marking my answer as correct and close this thread.

Regards,

Shloke

[mholmes]

As a follow-up, my plans crashed and burned because apparently, when reverting files from the "Skipped Changes to Review" interface, it does not care about application scope, but when you try to apply the update set to another instance, it cares very much.

I ended up with many preview problems of the form "Cannot commit Update Set 'Madrid Upgrade: Revert to Base System' because: Update scope id '{sys_id}' is different than update set scope id 'global'. Resolve the problem before committing." (I have an additional side problem where a handful of these conflicts are in scopes that are not accessible to me...how they were modified in the first place is anyone's guess, but the upshot is that I can't actually create an update set in the appropriate scope.)

All of this makes me leery of anything to do with "reverting" and Update Sets, so rather than go back and reassign each of my changes to a new, scope-appropriate update set (which is not even possible in some cases), I think I'm going to have to just go through and revert these items manually in each instance as I originally planned. At least I can export the file names from the Update Sets and use an "is one of" filter to do it quickly.