Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
Updating Choices in Scoped Applications - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • Updating Choices in Scoped Applications
KB0657356

Updating Choices in Scoped Applications


4799 Views Last updated : Nov 14, 2022 public Copy Permalink
KB Summary by Now Assist

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/csh?topicname=t_ResolveASkippedUpdate.html&version=latest


The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

Attachments

Attachments

  • Screen Shot 2017-12-10 at 1.52.37 PM.png
  • Screen Shot 2017-12-10 at 1.55.40 PM.png

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.