Working with Choices in ServiceNow - Support and Troubleshooting

Working with Choices in ServiceNow Description border-color:#E0E0E0; background-color: rgb(245, 245, 245); padding-top: .6em; padding-bottom: .6em; padding-left: .9em; padding-right: .6em; } table.noteTable{ border:1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); width: 100%; border-spacing:2; } table.internaltable { white-space:nowrap; text-align:left; border-width: 1px; border-collapse: collapse; font-size:14px; width: 85%; } table.internaltable th { border-width: 1px; padding: 5px; border-style: solid; border-color: rgb(245, 245, 245); background-color: rgb(245, 245, 245); } table.internaltable td { border-width: 1px; padding: 5px; border-style: solid; border-color: #E0E0E0; color: #000000; } .title { color: #D1232B; font-weight:normal; font-size:28px; } h1{ color: #D1232B; font-weight:normal; font-size:21px; margin-bottom:-5px } h2{ color: #646464; font-weight:bold; font-size:18px; } h3{ color: #000000; font-weight:BOLD; font-size:16px; text-decoration:underline; } h4{ color: #646464; font-weight:BOLD; font-size:15px; text-decoration:; } h5{ color: #000000; font-weight:BOLD; font-size:13px; text-decoration:; } h6{ color: #000000; font-weight:BOLD; font-size:14px; text-decoration:; } --> Overview This article covers working with choices in ServiceNOW. Choices are handled in a special manner and are treated as a special handler. This is important to know as it is pivotal in understanding how choices work in an instance. Choices are encompassed in a special handler known as a sys_choice_set. When a new choice is added to an existing element, that choice is captured in a sys_choice_set for that respective element.

From a customer updates perspective, sys_update_xml, when we add or update a choice, the name or update name displays a change for the sys_choice table. Here is an example:

If we view the payload of the sys_update_xml record, we see that the content not only contains any changes that are made, but it also contains all of the choices for that particular element on a particular table. This is because the change that was made is captured as a sys_choice_set. This means that we capture all of the choices within the existing sys_choice_set.

Why does this matter? The importance in knowing how choices are captured better equips users to understand how changes are applied when choices are moved primarily through an update set or through a scoped application. Since choices are captured in sys_choice_set, any changes applied to an instance that has choices always overwrites the existing choice set on the instance where the changes are being applied. Choices from one instance that are applied to another instance do not append or concatenate the changes. This is a common occurrence that is seen when moving choice changes between instances. Here is an example:

Instance 1: In instance 1, 2 new choices are created with the values of 9 and 10 off of the incident table where element is state. The choices are Happy(9) and Sad(10). In total, there are 8 choices within the sys_choice_set for table incident where element is state. These changes are captured in a local update set called Choices .

Instance 2: In instance 2, 2 new choices are created with the values of 14 and 12 off of the incident table where element is state. The choices are Bashful(14) and Grumpy(12). In total, there are also 8 choices with the sys_choice_set for table incident where element is state. These changes are captured only in the default update set.

Once the changes from instance 1 to instance 2 are applied, the choice additions added in instance 2, Bashful and Grumpy, are no longer present as the current choice set shows the choices from the choice set that is in instance 1. In this scenario, there is an error/warning generated as the changes applied from the update set Choices are older than the changes which exist on the target. In most cases that seen in support, customers add choices directly to their instances, which means that the last updated on would always be newer than the update set change that was being applied on the target which would not generate any preview errors. In this example, assume the intial changes made on the target where the update set changes are applied are newer than the changes that are being applied from the update set.

Unintentional Choice Updates/How to remediate There is a simple way to remediate sys_choice changes that overwrite existing choices on the target instance where you have applied a change. A sys_update_version record is created each time a modification is made to a choice. The simplest way to resolve an issue is to locate the previous version of the sys_choice record from the update versions table and then revert to the respective version that is needed. This remediation step can also be applied to other serviceNOW artifacts but customers should test before reverting versions in their production environment.

Using the example above, use the example that an admin realized that choices had been overwritten and needs to restore the choices for Bashful and Grumpy. The remediation step for this:

Grab the value from the name field on the customer updates table, sys_choice_incident_state Navigate to the sys_update_version table > sys_update_version.list Create a query for name contains the value from the name field for the customer update for the sys_choice change. Find the record where state is current, this is to identify what current version we are using for this particular artifact. Since the changes were applied from an update set called choices, the Source field should be reflective of this. Sort the list by C reated and locate the previous version that would have been the current version before the update set was applied. Open this record, and then in the related links, click Compare to Current . This brings up a diff checker to compare the current version to the last known version before the update was applied. From the diff checker, see the changes that existed pre-update set being applied. From the diff checker, click Revert to this Version . The current sys_choice set for incident where element is state should now be back to the way it was before the update set was applied.

A customer can revert to any version in the update versions table as needed. If for some reason it is needed to revert back the update set version, this is easily accomplished by performing the same steps performed for the update set version of the sys_choice record.

Recommendations The best recommendation for customers is to modify choices only in one instance and then move these changes throughout their environment as needed. Customers should never manually create choices on separate instances. Customers should follow the practice of cloning down from production to all environments to ensure that choices are all synchronized, or the same, across the board. Any addition, or modification, made to a choice should follow the normal development cycle, dev > test > prod, as this mitigates the possibility of unintentionally overwriting choices in an instance when applying an update set or a scoped application.