Updates to sys_choice table in update sets in DEV did not recreate when promoted to TEST and PROD

[Trish Mac]

Hello,

I have a catalogue item created by someone else where the dropdown list items for fields actually reside in the sys_choice table.  An underlying script makes the appropriate related dropdown entries appear along with a variety of UI policies. I needed to make extensive updates to the dropdown lists, so did these in Update Sets in DEV and promoted to TEST and PROD.

Unfortunately, not only did the changes NOT carry over, it seems to have wiped any entries in the sys_choice table in TEST and PROD environments, related to the Workflow-fnct element that any previous entries were created for.

Is there any way to bring in the data from the sys_choice table in DEV into TEST and PROD without having to manually update the table?  It is a LOT of data to update.

Thanks,

Trish

[Roshnee Dash · Accepted solution]

This is a classic ServiceNow issue— sys_choice is data, not configuration, and Update Sets behave badly with it if you’re not very deliberate. 

Why this happened (important context)

1. Choices live in sys_choice

   • They are table data, not metadata.

   • Deletes are dangerous → when promoted, they can wipe records in target instances if keys match.

2. Choices are matched by:

   • name (table)

   • element (field)

   • value

   • language

   • inactive

   If your DEV update set:

   • Removed choices

   • Renamed values

   • Recreated choices

   → ServiceNow may interpret this as “delete existing PROD choices and insert DEV ones”

3. Scripts / UI Policies don’t protect the data

   • They only control visibility.

   • If sys_choice records are gone, dropdowns break regardless.

Best ways to bring sys_choice data from DEV → TEST / PROD

 

This is the recommended approach for bulk sys_choice recovery.

Steps:

1. In DEV

   • Go to System Definition → Choices

   • Filter:

     • Table = <your table>

     • Element = Workflow-fnct

   • Select all relevant records

   • Right-click header → Export → XML

2. In TEST / PROD

   • Go to System Import Sets → Import XML

   • Upload the XML file

   • Preview

   • Import

✔ Preserves:

• Values

• Labels

• Language

• Order

• Active state

✔ No manual work
✔ No Update Set conflicts

[Trish Mac]

Hi Roshnee, I did resolve this in a somewhat different way then you suggested (see my explanation above).  I did end up with the desired outcome, I hope the way I did it will not cause me further trouble.

  Thank you SO much for the detailed explanation of why this happened.   Information all noted for future to help me make better decisions.  I've marked your response as the Correct Solution.

Thanks very much!

Trish

[Trish Mac]

So, it appears I've been able to resolve this.  I sorted the sys_choice table in DEV on the element of Workflow-fnct which all my updates were created for.  I then exported to .xml and then imported the .xml to the sys_choice table sorted on the Workflow-fnct element (which now had zero entries in the table in TEST).  The import was successful and my dropdowns have data now.  I repeated this process in Production with the same desired results.

The folks who use this are testing this out now to see if everything is as it should be.

I can't begin to say what a huge relief this is, as this was to go live on Monday.  Huge lessons learned - I went back and looked at the update sets and none of my changes to the sys_choice table were reflected in the Preview.  I was careless in assuming and cavalierly promoted the update sets in both environments.  A rookie error.  

I'm leaving this open for  now in the event anyone has any suggestions, comments, etc. with a better method than the one I've used to resolve this.

Thanks,

Trish