Skipped updates appear to have no conflicts

[mansfis]

Apologies if this is in the wrong space, I'm still very inexperienced!

I'm looking at upgrading our live instance to Geneva, and I'm looking at resolving the Skipped Updates on our test system. Searching through them some appear to have no conflicts - is this correct, or am I missing a conflict I can't see? If this is correct, why would the update be skipped (it is not skipped error)?

Thanks in advance.

[mansfis]

Ah, of that I'm not certain - I can't see anything in the documentation that would clarify, but if the Plugins are otherwise unchanged, I would imagine activating Plugins could be a cause. Certain Plugins are active in new instances starting in a certain version, but if you upgrade to that version, the Plugin is not activated until you change it manually. If the system expects a Geneva Plugin to have the same "Activated date" as Geneva itself, but it does not, that may show as a customisation.

I may be oversimplifying it, but if it expects to see a Plugin inactive, I would imagine the system expects the Updated field to be a certain value (eg when it was introduced), and activating it changes that date, therefore "customisation". However, is appears all of my Plugins were "updated" at 14:01 today, and I certainly didn't upgrade the system!

This appears to be caused by my account "Publishing" the Plugins. I'll keep my eye out for what might cause it to show as Updated, sorry I couldn't be more help than rambling speculation!

[peterraeves]

Not sure what is causing it, but I have it happen almost every time I just open the plugin list without doing anything. Maybe it checks for the latest versions first?

[mansfis]

Yeah, I've checked it again this morning and it's updated again. I logged out and in yesterday and it didn't update, yet this morning on the same session as last night it changed that field. Odd!

[peterraeves]

It probably only checks if it hasn't checked in the last X hours, regardless of the session or the person checking. Just my 2 cents, I'm not a SN employee.

[richfred]

The "skipped error" records in the upgrade history usually contains sys_properties data, that may already have been set in your instance. You can review the conflicting data to confirm the values and if the values are the same, you can leave the record as skipped. Most of these skipped error records also has a Priority of 5(low).

when you do a check on the skipped error records your will see that mostly the reason why this was the disposition of these updates is that it belong to a Scoped App Author or the Scoped App Client applications. Take note that these sys_properties are existing in your instance already.

Opening the Show Related Record link for these records results to the message below and no option to edit the record at all:

"This record is in the Scoped App Author application, but Global is the current application. To edit this record click here."

In comparison, open a record with Disposition "skipped" and you will have the options to Resolve Conflicts(comparison of Base system vs. Custom)or Revert to Base System.

Lastly, based on the Priority grade of these skipped error records should not have any effects on the behavior and functionality of your instance.