Upgrading Apps and managing conflicts
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-28-2015 10:32 AM
Hey guys,
I'm wondering what others experiences are when a customer does an upgrade to a new version of the app. We recently released a new version and I got to watch a customer go through the process of doing the actual upgrade. They were totally blown away by how easy it was and how it was rather safe because nothing was overwritten. We don't protect or make readonly any of the Business Rules or Script Includes in our app so customers can and do make changes in accordance with their business use cases.
However, one thing I found rather lacking was a way to see in one place all of the collisions. For example, if we have 5 Script Includes and 3 business rules as part of the app. The customer then makes changes to 2 Business Rules and a Script Include, then with the new version, we have to update all 5 Script Includes and all 3 Business Rules. As it is now, after the upgrade, the customer must go into each of the 8 records and visually inspect the Revision History for any that weren't upgraded.
So, I'm curious how you guys handle the following:
- Is there a central place to see all the revisions needing to be reviewed?
- Does the "compare" work for you guys? When I check the box next to the current and one other revision item, then select the "Compare" option from the actions drop down, nothing happens... no form refresh, no new dialog... am I missing something?
- How do you test or document the upgrade? As far as I can tell, we can't install a previous version to our ven instances, so we really only have one shot to test or document the upgrade.
I'd be interested in your feedback on how you handle upgrades from apps in the store.
Thanks!
--- Travis
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-28-2015 06:48 PM
Sorry if I misunderstand, but I think you're talking about update sets. If this is the case, when you have collisions they appear during the preview phase of the migration/promotion to the new instance. A tab appears and an alert tells you that you must address each collision before you can proceed with the update. In these instances I've found the compare/diff feature to be pretty helpful, although it's possible that sometimes what an object is missing there is nothing to actually show during the compare. Finally the test/validation phase is best handled by a test run in a subproduction instance. If you have three instances you're in great shape since you can build in DEV then clone down PROD to a middle instance (TEST, QA, whatever) and do your dryrun there. The extent of testing depends on the complexity of the update set - sometimes you need to do full end-to-end regression testing and sometimes you can get away with just smoke testing, depending on the scope of your updates. Hope this is helpful info - good luck!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-28-2015 07:08 PM
Hey Mike,
Yes, I'm aware of the Update Set compare and that is exactly what I'm looking for. Unfortunately, this isn't available (as far as I can tell?) for upgrading scoped apps because they come from the store, not from update sets.... again, going back to item 3 where we can't really test it... so it might be available in Update Sets, but I can't tell.
Thanks.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2016 10:31 PM
I have observed the following so far, but I cannot be 100% sure. Would love confirmation.
-Installing/Upgrading applications does not commit updates that would be a 'error' if committed by an update set
-Installing/Upgrading applications does not commit updates that would be a 'warning' if committed by an update set
ServiceNow Nerd
ServiceNow Developer MVP 2020-2022
ServiceNow Community MVP 2019-2022
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2016 11:15 PM
Paul, I have seen that. If you go into each individual record, you will see the "local" record is still there, and the "remote" record (the one coming from the new version of the application) is listed as a version. As far as I can tell, you have to go into each record and manually merge the changes, or mark the "remote" record as the current.
One thing that I have found slightly helpful is the System Diagnostics > Upgrade History. This shows the same kind of report you are used to seeing in the update set preview. I haven't used this yet on a test upgrade, but I'd like to hear how others are using it.
Happy Sunday