skipped records during upgrade

David Christian · ‎03-12-2018

We just upgraded to Kingston. Normally we have thousands of skipped records to review (We've done two other upgrades). This time we have less than a thousand. We have about one tenth of what we have had each time in the past. Has anyone else had this happen? Am I missing something as to why it is so different this time?

Chuck Tomasi · ‎03-12-2018

Hi David,

Starting in Jakarta, there's a new related list in the Upgrade History that allows you to see what skipped changes need reviewing. It's called "Skipped changes to review".

You can use the list filter to take out Priority 5, for example and get a much smaller list of things to review that really matter. I.e. it skips sys_documentation records which include things like field label changes. Not critical for testing and review, right?

View solution in original post

JV6 · ‎05-15-2018

Hey Chuck,

Is it best practice to generally go through all of the Skipped Records and review them? What do we gain out of that?

And as you mentioned below if during the next upgrade, the same skipped customization shows up again, wouldn't it generally just gradually build up over time?

And if we follow best practice and inactivate a business rule, make a copy of it, and change our copy, the old business rule still triggers a Skipped change correct?

Chuck Tomasi · ‎05-16-2018

The key to making the skipped changes related list to is to focus on what's important. Filter out the P5 (or others) as you generally don't want to bother with field labels and choice lists being changed. That makes the list MUCH shorter.

Two schools of thoughts on the "deactivate and copy" scenario.

1) If you make a copy and deactivate the original, you avoid the conflict message if the item was upgraded. Hurray - no conflict!

2) If you modify the original and it gets upgraded, you now get the conflict message, but better yet, you KNOW it was upgraded instead of silently missing it in the background somewhere. You have a choice at this point, but it's also a little more work.

JV6 · ‎05-17-2018

Great that's very helpful.

And what's your view in terms of reviewing this in either DEV or PROD? Because I know when I Review and Retain/ Merge, it doesn't get captured in an update set but when I Review and Revert it does get captured.

Maybe review it all in Dev first and if we do have stuff to revert capture those in an update set and move them to PROD? But it wouldn't say that it was reviewed but I guess that doesn't matter so much.

jas101 · ‎12-11-2019

Hi. This is a really good point - anyone have any comments as to best practice regarding this? I.e. is it expected that you re-review skipped changes in each instance or if you've done it once in Dev, do you just capture any 'Reverts' in an update set and apply this to Test and Prod (presumably pre-upgrade to those instances)!?

It's a shame other actions on reviewed records don't get captured to make upgrade skipped changes reviews easier. Unless this is deliberate for some reason I'm missing?

Thanks in advance Chuck.

Archana13 · ‎07-23-2020

Thanks Chuck.

I need to know the meaning of displaying dots in color e.g. Priority 2 displays with red color and Priority 5 display with green color.

I also observed under upgrade history few records are with number e.g. 7, 8 etc where some records are shown with skipped state. what does this mean.

Thank you.