Will activating inactive sys_choice records affect a Choice field populated by a Client Script? ✅

[harshal001]

Hi everyone,

I have a question regarding dynamically populated choice fields in ServiceNow.

I have a choice field (u_fault_category) whose options are populated entirely through a Client Script. The script first clears all existing options and then adds only the required choices based on the value of another field (u_operations_category).

Example:

g_form.clearOptions('u_fault_category');
g_form.addOption('u_fault_category', '', '-- None --');
g_form.addOption('u_fault_category', 'hardware_replacement', 'Hardware Replacement');
// Additional options...

Currently, many of the corresponding sys_choice records for u_fault_category are Inactive.

My question is:

• If I make those sys_choice records Active again, will it affect the behavior of my Client Script?

• Since the script calls g_form.clearOptions() before adding the required choices, will the active sys_choice records still have any impact on the form?

• Could activating the choices affect other platform components such as Flow Designer, Import Sets, REST APIs, Agent Workspace, or anywhere the Client Script does not execute?

Has anyone encountered this scenario or can explain the best practice for handling dynamically filtered choice lists?
#ServiceNow #Client_script #Choice_mapping

Thanks in advance for your guidance!

[vaishali231 · Accepted solution]

Hey @harshal001 

From my experience, activating the sys_choice records will not change the behavior of your Client Script, provided the script executes successfully.

The reason is that g_form.clearOptions('u_fault_category') removes all choices currently available on the form, including those loaded from the dictionary (sys_choice). After that, your script explicitly adds back only the options you want with g_form.addOption(). In that scenario, the active/inactive state of the sys_choice records does not affect what the end user sees.

However, it's important to consider components where Client Scripts do not run or are not the primary mechanism:

1. Flow Designer
2. Import Sets / Transform Maps
3. REST or SOAP API integrations
4. Background Scripts
5. Server-side Business Rules
6. Some Workspace, Mobile, or UI Builder experiences depending on the implementation

These components rely on the underlying dictionary and sys_choice data rather than the client-side filtering. If you activate all of the choice records, those values may become available in these contexts even though they remain hidden on the classic form by your Client Script.

Best practice is to avoid using Client Scripts as the only mechanism for enforcing valid choices. Client-side filtering is great for improving the user experience, but if certain values should never be accepted, implement server-side validation (Business Rule, Script Include, Data Policy where appropriate, etc.) so that imports, integrations, and other entry points cannot bypass the restriction.

So in summary:

1. Active sys_choice records will not affect your Client Script because clearOptions() removes them before your custom options are added.
2. They can affect other platform components that don't execute your Client Script.
3.  If the choices are activated, test all entry points (Classic UI, Workspace, Flow Designer, APIs, and imports) to ensure the behavior remains consistent.

This approach provides the flexibility of dynamic UI filtering while maintaining data integrity across the platform.

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[Ehab Pilloor]

Hi @harshal001,

If you are using Client Script to populate choices, it is best to add new choices in the script itself, since your script has clear options method, It will remove all existing choices and show what you have added via script. Even if you make choices active, those wont be visible as long as script conditions are met. Existing choices dont affect your client script. If your script condition is met, they will be cleared in that session and if you want it, you will have to add those options as part of your script in that session.

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.

Regards,

Ehab Pilloor

[Ehab Pilloor · Accepted solution]

@harshal001,

If above response helped with your query, please mark it as Solution too so that it helps future readers understand this was essential in answering your question.

Thank you.

[vaishali231 · Accepted solution]

Hey @harshal001 

From my experience, activating the sys_choice records will not change the behavior of your Client Script, provided the script executes successfully.

The reason is that g_form.clearOptions('u_fault_category') removes all choices currently available on the form, including those loaded from the dictionary (sys_choice). After that, your script explicitly adds back only the options you want with g_form.addOption(). In that scenario, the active/inactive state of the sys_choice records does not affect what the end user sees.

However, it's important to consider components where Client Scripts do not run or are not the primary mechanism:

1. Flow Designer
2. Import Sets / Transform Maps
3. REST or SOAP API integrations
4. Background Scripts
5. Server-side Business Rules
6. Some Workspace, Mobile, or UI Builder experiences depending on the implementation

These components rely on the underlying dictionary and sys_choice data rather than the client-side filtering. If you activate all of the choice records, those values may become available in these contexts even though they remain hidden on the classic form by your Client Script.

Best practice is to avoid using Client Scripts as the only mechanism for enforcing valid choices. Client-side filtering is great for improving the user experience, but if certain values should never be accepted, implement server-side validation (Business Rule, Script Include, Data Policy where appropriate, etc.) so that imports, integrations, and other entry points cannot bypass the restriction.

So in summary:

1. Active sys_choice records will not affect your Client Script because clearOptions() removes them before your custom options are added.
2. They can affect other platform components that don't execute your Client Script.
3.  If the choices are activated, test all entry points (Classic UI, Workspace, Flow Designer, APIs, and imports) to ensure the behavior remains consistent.

This approach provides the flexibility of dynamic UI filtering while maintaining data integrity across the platform.

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[harshal001]

@vaishali231  Thank You for knowledge sharing.