Application and Plugins Update - Best Practices

[mfhaciahmetoglu]

Hello community,

I have some questions/concerns concerning applications and plugin updates.

Let me give you the context first:

- Our instance has been mildly customized.

- We want to update all plugins and applications to be up to date.

Now, my questions/concerns have to do with "how one should manage the process of updating applications and plugins"?

• Is there a distinction between updating a plugin and updating an application? Do we need to check or be attentive to anything specific when we update a plugin and an application? 
  • I am asking this because when I update a plugin, I see that there is actually NOT any next version. There are  "Customized version installed" and "Latest customized version". And updating a plugin basically updates "Customized version installed" part. And it also does not generate any skipped changes record understandably.
    • What does this mean?
      • My understanding is that when we update a customized plugin, what we do is basically to define a new base version for the applications. Because some applications, in turn, are configured on these new based versions? Is this true?
      • Also sometimes, when I update an application, it asks me to choose either a base version or None? What is the best practice here? 
        • 
• When I update some applications, I see that there are customizations. 
  • SN has a KB about this: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0869183
    • I conclude from this KB that:
      • No amount of customization would cause any problem when we update applications (if there is no external vendor involved), as these changes will be skipped, meaning that customizations will be retained.
        • I see though sometimes that skipped errors are generated, any idea what these are? There is no action on our side possible to do anything about this but would like to understand their significance.
        • I also see sometimes that skipped records are generated. I can find these on sys_upgrade_history table. If these are sys_properties or other system parameters of priority-5, I usually check how important they are and then I revert back to the base system. But sometimes, rarely though, they are of higher priority. What shall I do in this case? Why are these changes not skipped during the upgrade? 
          • BTW, are you also using sys_upgrade_history table for skipped records? What are the best tables to check for applications/plugins upgrade?
• One weird thing we experienced before: 
  • I updated an application. There were some UI-customizations on the workspace view. After the update, only one of these customizations was removed and I had to put it back. 
    • This worries me a bit because I then cannot fully trust the operation. On the other hand, there is no ATF set up fully on our instance to check all use-cases. 
    • How can we rule out this possibility that updates will result in unexpected consequences for some use-cases (e.g., removing a custom field from the form)? Is ATF a must when a plugin/applications has more than 100, even sometimes 1000 customizations, given that we cannot test all use cases?

Thank you very much for your time and help.

Best,

Firat

[CezaryBasta]

See this page to answer your first bullet point. When you publish a customization to the plugin in your own company repo, then you will see the Customized Version dropdown. It means that you fork the application development and you manage it on your own. If you go back to the store version, I guess you would loose all customizations developed.

Skipped errors and skipped records are always generated during an upgrade of anything (plugin or instance). It's best practice to review them and act on them. Some may be ignored, but sometimes you will notice dependencies being upgraded that brake your customizations. Automatic categorization does not always catch those.

I had similar issue with upgrade:

• I upgraded the OOB plugin
• I noticed that it broke the order of the widgets on one of its pages on the SP
• After reviewwing the skipped records, I found out that one update added a new column to the page and another update was responsible for assigning widgets to that new column.
• Since I had the page customized, the widget to column assignment was ignored - but the new column was there

Just remember to review your skipped records 🙂

[mfhaciahmetoglu]

Thank you very much for your answer.

Are you also checking for the skipped records on this table? now/nav/ui/classic/params/target/sys_upgrade_history_list.do

I do not see that many records are generated for the updates I have performed, which is weird. 

[mfhaciahmetoglu]

Hello,

Just a follow-up on this after doing the updates.

The result was a mess, to be honest. 

I suggest anyone updating the applications be extra cautious because we experience the following effects:

- We were told that once an application is updated, ServiceNow will create skipped records for the customizations in that application. However, this is not entirely true for two reasons.

1. It is not true because it is simply the case that SN sometimes automatically reverts the customizations back to the base version without ever creating a skipped records.

2. It is not true because even when SN creates skipped records, it is simply not possible to keep the customizations. This is misleading because although on the system, it says "Skipped" but if you look at the comments, you can see "Superseded by App Customization" comment. This means that, as far as I understood, the customization is reverted back to the base version that comes with the update. And there is no way to revert back to the customized version.

This is super annoying because you simply lose your customization and there is no way to go back and sometimes you don't even know which customizations are lost.

This is my experience. We opened to HI Tickets with SN but no solution or satisfactory remark so far.

How to proceed further? 

It is not clear without knowing why this happens but be cautious.

Best,

Firat