Issue
Updating Choices in Scoped Applications
Overview
This article addresses updates to choice list specifically in a scoped application. The medium which customers use to move choice changes within a choice set is usually done with update sets however, capturing changes to choices in scoped app and then applying the updated changes exhibits a different behavior from what is normally expected in changes to choices in an update set.
Choices with an Update Set
In an update set when changes to choices are made and then applied to an instance the system takes the latest update and then applies the changes as an entire choice set. See KB0656146 for working choices if you are new to how choices work. This means we only apply 1 update containing the latest changes.
In the screen shot shown, there are two new choices which I have added to element incident_state on the incident table. When viewing sys_update_xml notice there is a single update made to sys_choice_incident_incident_state even though two choices have been added.
In this example the changes are captured in the default update set, but if a local update set had been created, and then made the changes the same behavior occurs. If we were to have captured this in a local update set called choice test and then applied it to another instance we would then overwrite the existing choice set wherever we are applying these changes, but there would only be 1 update to the choice set for incident_state on the incident table.
Choices in a Scoped Application
On initial install of a scoped app, choices are loaded as one single update. However when subsequent changes are made to a choice set, more choices are added to an existing element, the number of updates loaded when we update the scoped app from an instance where the scoped application is installed will apply for as many times as there are updates. This is important as from an update set that no matter how many changes are made to a choice set by adding more choices we always load the latest version of that choice set. In the case of a scoped app this is not the same behavior as we load an update for every single change that was made. In the example above, if we were to have installed a scoped app which had the choices for incident state and then updated the application with the two new choices that were created we would expect to see 2 updates in the localhost logs instead of just 1.
Why is this important?
Knowing how choices work within an update of a scoped app is important as the install process can take a long time if working with a choice set that is large with a large number of updates. Take for example a choice set that has 500+ choices and then a user decides to add 600 new choices. On update of the scoped app in the localhost logs we would see 600 updates which then loads the entire choice, which is current choices +1 (new choice that was added). From a logical point of view in knowing how choices work, we should only care about the latest update as this would include every new change added up to the point of the latest change. There has been a bug filed for this behavior which is still under review and the fix most likely will be available in a new release, which means any current version now would exhibit this behavior.
Recommended Approach
The following recommendations are only intended for users who are affected by PRB1240837, which causes long app install times when large numbers of choices are present in a scoped app. If the choice set that a user is working with is small and the number of updates is small updates via the app repo can be used. However, due to the aforementioned PRB, if we are dealing with a very large choice set and have a large number of updates, it is best to create a local update set within the scoped app and then capture the changes and utilize the update set method to move over changes as needed.
NOTE: If you are already using the app repo to publish your scoped application, do not use update sets to migrate changes. Using update sets and the app repo together will cause conflicts in the upgrade engine when downloading updates to the scoped app. This will result in changes not being applied in the target instance until the conflicts are addressed. Thus, if using an update set as a workaround, you will need to check for skipped changes during your next installation by following the instructions in this documentation: https://docs.servicenow.com/bundle/london-platform-administration/page/customer-support/task/t_ResolveASkippedUpdate.html