How choices work in ServiceNow and how to manage choice changes across instancesIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Understand how choices work in ServiceNow, how they are captured in update sets, and how to manage choice changes across instances. In ServiceNow, choices are stored and managed as a special data type called a sys_choice_set. When a new choice is added to an existing field element, that choice is captured in the sys_choice_set for that element. This is important to understand because it affects how choices behave when changes are moved between instances. When a choice is added or updated, the Customer Updates [sys_update_xml] table records a change entry for the sys_choice table. The payload of that sys_update_xml record contains not just the individual change, but all choices for that element on that table — because the change is captured as a complete sys_choice_set snapshot. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All supported releases Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } How choices behave when moved between instances Because choices are captured as a complete sys_choice_set snapshot, applying a choice change to an instance always overwrites the existing choice set on the target instance. Choices are not appended or merged — the entire choice set is replaced. This is a common source of unintentional overwrites when moving choice changes between instances via update sets or scoped applications. Example Instance 1: Two new choices — Happy (9) and Sad (10) — are added to the Incident [incident] table where the element is State. The choice set for that element now has eight choices total. These changes are captured in a local update set called Choices. Instance 2: Two new choices — Bashful (14) and Grumpy (12) — are added to the same element on the Incident [incident] table. The choice set also has eight choices total. These changes are captured only in the default update set. When the update set from instance 1 is applied to instance 2, the Bashful and Grumpy choices are no longer present because the choice set from instance 1 replaces the choice set on instance 2. In this scenario, a warning may be generated if the changes in the update set are older than the existing changes on the target instance. In practice, when choices are added directly to an instance, the last updated date on the target is typically newer than the update set change being applied — which means no preview errors are generated, and the overwrite may go unnoticed. How to restore overwritten choices When a choice set is overwritten after applying an update set, you can restore the previous version using the Update Versions [sys_update_version] table. A sys_update_version record is created each time a choice is modified, which makes it possible to revert to any previous state. Note: This remediation approach also applies to other ServiceNow artifacts. Always test version reverts in a non-production environment before applying them to production. The following steps use the earlier example where the Bashful and Grumpy choices were overwritten and need to be restored. Go to the Customer Updates [sys_update_xml] table and locate the update record for the choice change. Copy the value from the Name field — for example, sys_choice_incident_state.Go to /sys_update_version_list.do.Filter the list where Name contains the value copied in step 1.Find the record where State is Current. This identifies the version currently applied for this artifact. If the changes were applied from an update set called Choices, the Source field reflects this.Sort the list by Created and locate the version that was current before the update set was applied.Open that record and select Compare to Current in the related links. A diff view opens showing the differences between the current version and the earlier version.Review the earlier state of the choice set, then select Revert to this Version.The choice set for the Incident [incident] table where the element is State is now restored to its state before the update set was applied. You can revert to any version in the Update Versions table using these steps. To restore the update set version specifically, follow the same steps and select the update set version of the sys_choice record. General guidelines for managing choices Follow these guidelines to reduce the risk of unintentional choice overwrites across your instances: Modify choices in one instance only, then move those changes to other environments as needed.Do not manually create choices on separate instances.Clone down from production to all environments regularly to keep choice sets synchronized across your instance pipeline.Follow the standard development cycle — development, test, production — for all choice additions and modifications. This reduces the risk of unintentionally overwriting choices when applying update sets or scoped applications.