sys_choice Table — ServiceNow Reference

Table Reference/sys_choice

The sys_choice table stores all choice list options for every choice field across all ServiceNow tables. It's the master repository that powers dropdown menus, with each record defining a single option identified by table name + element name.

What This Table Is

The sys_choice table is the centralized dictionary for all choice field options across the entire ServiceNow platform. Every dropdown menu, radio button set, and select list pulls its options from this table. When you create a choice field on any table, the individual options are stored here as separate records.

This table is owned by the Platform module and supports the core data dictionary functionality. Each record represents a single choice option with a unique combination of name (table name) and element (field name). The value field contains what gets stored in the database, while label contains what users see on forms.

The sys_choice table doesn't extend any other table and no tables extend it. However, it has a critical relationship with sys_dictionary which defines the choice fields themselves, and sys_choice_set for managing choice sets that can be reused across multiple fields.

In large enterprise instances, this table typically contains 15,000-50,000+ records. Performance is generally good for lookups by name and element since these fields are indexed, but full table scans can be expensive due to the volume and the fact that every form load potentially triggers choice lookups.

When You'll Script Against This Table

You'll most commonly script against sys_choice in Script Includes for choice management utilities, Business Rules that need to validate choice values, and Client Scripts that dynamically filter or populate choice fields. Data imports and integrations frequently query this table to validate incoming choice values or build choice mappings. UI Actions and processors also hit this table when building dynamic forms or choice-dependent logic.

The admin role has full access to this table. Most other roles can read choice records but cannot modify them. The personalize_choices role allows users to add personal choice options. Global scope can access all choices, but scoped applications can only modify choices for fields in their scope.

Common scripting patterns:

Validating user input against valid choice values before database writes
Building dynamic reference qualifiers based on choice field values
Creating choice-to-choice dependencies where one field's options depend on another
Programmatically adding or deactivating choice options during customization
Translating choice labels for multi-language implementations
Building choice mappings for data imports from external systems
Retrieving choice labels for display in reports or notifications

Table Gotchas

⚠️

The value field stores what goes in the database, but sequence controls display order, not value. A choice with value='1' might display last if its sequence is 1000.

⚠️

Inactive choices (inactive=true) still exist in the database and can still be set programmatically - they just don't appear in the UI choice list.

The name field stores the table name, not a display name - use exact table names like 'incident' not 'Incident'
Choice values are always stored as strings, even for integer choice fields - your comparisons need to account for string coercion
Language field controls translation - empty language means base language, specific language codes override for that locale

⚠️

Queries without name + element filters are extremely expensive. Always filter by both fields when possible - never do full table scans on sys_choice.

The dependent_value field creates cascading choice dependencies but requires exact value matches, not labels

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The sys_dictionary table defines the choice fields themselves - you'll often query both tables together when building field management tools or validating field configurations. The sys_choice_set table manages reusable choice sets that can be applied to multiple fields, and choice_set field in sys_choice references it.

The sys_db_object table is commonly joined when you need to validate table names in choice records. For internationalization, sys_translated stores additional translations beyond the base language field functionality.

Any table with choice fields will be queried alongside sys_choice for validation or label lookup. Common examples include incident (state, priority, urgency), task (state), and sys_user for any custom choice fields added to user records.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
name	string	Table	The exact table name where this choice field exists. Must match sys_db_object.name exactly, case sensitive.
element	string	Element	The field name on the table that uses this choice. Combined with name field creates unique identifier for the choice field.
value	string	Value	The actual value stored in the database when this choice is selected. Always stored as string regardless of field type.
label	string	Label	The display text shown to users in the UI. Can differ from value and supports special characters and spaces.
sequence	integer	Sequence	Controls display order in choice lists. Lower numbers appear first. Gaps in sequence numbers are normal and don't affect functionality.
inactive	boolean	Inactive	When true, choice doesn't appear in UI dropdowns but can still be set programmatically and existing records retain the value.
language	string	Language	Language code for internationalization. Empty means base language, specific codes like 'en' or 'es' override for that locale.
dependent_value	string	Dependent value	Creates cascading choice dependencies. This choice only appears when the dependent field has this exact value (not label).
choice_set	reference	Choice set	References sys_choice_set for reusable choice collections. When populated, this choice is part of a managed set.
hint	string	Hint	Optional tooltip text displayed when hovering over the choice option in forms. Useful for providing additional context.

Common Queries

Get all active choices for a specific field

// Most basic query - get choices for incident state field
var gr = new GlideRecord('sys_choice');
gr.addQuery('name', 'incident');
gr.addQuery('element', 'state');
gr.addQuery('inactive', false);
// Order by sequence to match UI display order
gr.orderBy('sequence');
gr.query();
while (gr.next()) {
    gs.info('Value: ' + gr.getValue('value') + ', Label: ' + gr.getDisplayValue('label'));
}

Find choices by table and language for internationalization

// Get Spanish translations for priority field choices
var gr = new GlideRecord('sys_choice');
gr.addQuery('name', 'incident');
gr.addQuery('element', 'priority');
gr.addQuery('language', 'es');
gr.addQuery('inactive', false);
gr.orderBy('sequence');
gr.query();
// Fall back to base language if no translations found
if (!gr.hasNext()) {
    gr.initialize();
    gr.addQuery('name', 'incident');
    gr.addQuery('element', 'priority');
    gr.addQuery('language', '');
    gr.query();
}

Validate if a value exists for a choice field during data import

// Business scenario: validate imported incident state values
function isValidChoiceValue(tableName, fieldName, valueToCheck) {
    var gr = new GlideRecord('sys_choice');
    gr.addQuery('name', tableName);
    gr.addQuery('element', fieldName);
    gr.addQuery('value', valueToCheck);
    gr.addQuery('inactive', false); // Only check active choices
    gr.query();
    
    if (gr.next()) {
        gs.info('Valid choice: ' + gr.getDisplayValue('label'));
        return true;
    }
    return false;
}

// Usage example
var isValid = isValidChoiceValue('incident', 'state', '6');

Count choices per table to identify heavily customized tables

// Use GlideAggregate to count choice options by table
var ga = new GlideAggregate('sys_choice');
ga.addQuery('inactive', false);
ga.addAggregate('COUNT');
ga.groupBy('name');
ga.orderByAggregate('COUNT');
ga.query();

gs.info('Tables with most choice customizations:');
while (ga.next()) {
    var tableName = ga.getValue('name');
    var choiceCount = ga.getAggregate('COUNT');
    if (choiceCount > 50) { // Focus on heavily customized tables
        gs.info(tableName + ': ' + choiceCount + ' choices');
    }
}

Wrong way vs right way to query dependent choices

// WRONG: This misses dependent choices and is slow
// var gr = new GlideRecord('sys_choice');
// gr.addQuery('element', 'subcategory');
// gr.query();

// RIGHT: Always include table name and consider dependencies
var parentValue = '2'; // Software category value
var gr = new GlideRecord('sys_choice');
gr.addQuery('name', 'incident');
gr.addQuery('element', 'subcategory');
// Get choices that have no dependency OR depend on parent value
var condition = gr.addQuery('dependent_value', '');
condition.addOrCondition('dependent_value', parentValue);
gr.addQuery('inactive', false);
gr.orderBy('sequence');
gr.query();
// This properly handles cascading choice relationships

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

sys_choice