sys_dictionary Table — ServiceNow Reference

Table Reference/sys_dictionary

The System Dictionary (`sys_dictionary`) is the platform's metadata registry, containing one row for every field on every table in the instance. Owned by the Platform module, it's the authoritative source for table schema information and field definitions.

What This Table Is

The sys_dictionary table is ServiceNow's complete field metadata registry. Every field on every table—from incident.short_description to custom fields on your application tables—has exactly one row here. It stores field types, labels, default values, reference qualifiers, and every other piece of schema information.

This table is owned by the Platform module and serves as the foundation for all schema introspection. When you right-click a field and choose "Configure Dictionary", you're editing this table. When the platform validates field types or builds form layouts, it reads from here.

The sys_dictionary table doesn't extend any parent table—it's a standalone system table. However, it's intimately connected to sys_db_object (table definitions) and sys_glide_object (field metadata extensions). The relationship is: one table has many fields, one field has one dictionary entry.

In large enterprise instances, expect 50,000+ records here. That includes every field on every table, including inactive tables and fields. Queries against this table are generally fast—the platform indexes it heavily since schema lookups happen constantly—but avoid wildcard searches on element field names without table filtering.

When You'll Script Against This Table

You'll primarily script against sys_dictionary in Script Includes for platform utilities, Business Rules that need field validation, and background scripts during data migrations. The most common pattern is checking whether fields exist before trying to use them programmatically. You'll also query it in Transform Maps when building dynamic field mappings.

Access requires the admin role for write operations, but most users can read dictionary entries for tables they can access. Scoped apps can only see dictionary entries for their own tables unless explicitly granted cross-scope access.

Field existence validation before dynamic queries
Building dynamic form layouts or field lists
Data migration scripts that need field type information
Integration utilities that inspect target table schemas
Custom field documentation or schema export tools
Reference qualifier builders that need related table information
Platform upgrade scripts validating custom field compatibility

Table Gotchas

⚠️

The `name` field combines table and field: it's 'incident.short_description', not just 'short_description'. Always filter by both `name` and `element` or you'll get unexpected results across table inheritance.

⚠️

Table extension inheritance isn't visible here directly. A field on the `task` table appears in dictionary entries for `incident`, `problem`, etc. Check the `sys_db_object` table for inheritance chains.

The active field only marks the dictionary entry as inactive, not the actual database column. Inactive fields still exist in the database and can still be queried.
Reference fields store their target table in reference, but choice fields store their choice list in the same field. Check internal_type to distinguish field types properly.
The column_label field is translatable and may show different values based on user language. For consistent scripting, use element (the actual field name) instead.

⚠️

Queries without table filtering perform poorly. Always include `name LIKE 'your_table.%'` or filter by the full `name` field. Wildcard searches on `element` alone will timeout on large instances.

Calculated fields and client-side computed values won't have meaningful default_value entries. The business logic lives elsewhere (Script Fields, UI Policies, etc.).

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_db_object table is the natural partner—it defines tables while sys_dictionary defines their fields. When building schema documentation or migration tools, you'll query both together to get complete table definitions. The sys_dictionary.name field contains the table name from sys_db_object.

You'll frequently cross-reference with sys_choice when working with choice fields—the dictionary entry tells you it's a choice field, but sys_choice contains the actual choice values. Similarly, sys_glide_object extends dictionary entries with additional field behaviors like attributes and advanced configurations.

For reference fields, you'll often need to join with the target tables themselves. When a dictionary entry shows reference=sys_user, you might then query sys_user to understand what values are available for that reference field. This pattern is common when building dynamic UI components or integration mappings.

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.element	Combines table and field names as 'table_name.field_name'. This is the unique identifier and the field you'll filter on most often.
element	string	Column name	The actual field name without the table prefix. Use this when building GlideRecord queries dynamically or when you need just the field name.
column_label	translated_field	Column label	The display name shown on forms and lists. This field is translatable and changes based on user language—don't use it for programmatic field identification.
internal_type	choice	Type	The actual field type (string, integer, reference, choice, etc.). This is the definitive source for field type—more reliable than inferring from other fields.
reference	string	Reference	For reference fields, contains the target table name. For choice fields, contains the choice list name. Check internal_type to distinguish between the two.
active	boolean	Active	Controls whether the field appears in forms and schema tools. Inactive fields still exist in the database and can still be queried—this just hides them from the UI.
read_only	boolean	Read only	Makes the field non-editable in the UI. This is a UI-level restriction and doesn't prevent programmatic updates via GlideRecord or Import Sets.
mandatory	boolean	Mandatory	Enforces required field validation on forms. Business Rules and server-side scripts can still save records with empty mandatory fields if they bypass form validation.
default_value	string	Default value	Static default value applied to new records. Dynamic defaults (like JavaScript expressions) are stored here as code strings, not the evaluated results.
max_length	integer	Max length	Character limit for string fields. The database enforces this limit—attempts to insert longer strings will be truncated silently or cause errors depending on the field type.
display	boolean	Display	Controls whether the field appears on forms by default. Fields can still be added to forms manually even when this is false.
virtual	boolean	Virtual	Indicates fields that don't exist as database columns (calculated fields, dot-walked references, etc.). Virtual fields can't be indexed or used in certain query contexts.
unique	boolean	Unique	Enforces database-level uniqueness constraint. This creates a database index and prevents duplicate values—violations will cause save operations to fail with an error.
choice	integer	Choice	Indicates choice field behavior: 0 = none, 1 = dropdown, 2 = suggestion, 3 = dropdown with none. The actual choice values are stored in the sys_choice table.
dependent	string	Dependent	For dependent choice fields, specifies the controlling field name. The choice values change based on the controlling field's value, with mappings stored in sys_choice.
function_definition	string	Function definition	JavaScript code for calculated fields and default value functions. This code executes server-side when the field value is needed.
function_field	boolean	Function field	Marks calculated fields that derive their values from function_definition code. These fields are computed dynamically and can't be directly updated.
reference_qual	string	Reference qual	Reference qualifier that filters available choices in reference fields. Can be static conditions or JavaScript functions that return query conditions.

Common Queries

Get all active fields for a specific table

// Most common query - inspect schema for a table
var gr = new GlideRecord('sys_dictionary');
gr.addQuery('name', 'STARTSWITH', 'incident.');
gr.addQuery('active', true);
gr.orderBy('element');
gr.query();

while (gr.next()) {
    gs.print(gr.element + ' (' + gr.internal_type + '): ' + gr.column_label);
}

Find all reference fields pointing to a specific table

// Find fields that reference sys_user across all tables
var gr = new GlideRecord('sys_dictionary');
gr.addQuery('internal_type', 'reference');
gr.addQuery('reference', 'sys_user');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    var tableName = gr.name.toString().split('.')[0];
    gs.print(tableName + '.' + gr.element + ' references sys_user');
}

Check if a custom field exists before using it in migration

// Validate field exists before migration script runs
function fieldExists(tableName, fieldName) {
    var gr = new GlideRecord('sys_dictionary');
    gr.addQuery('name', tableName + '.' + fieldName);
    gr.query();
    
    if (gr.next()) {
        gs.info('Field ' + fieldName + ' found, type: ' + gr.internal_type);
        return true;
    }
    gs.warn('Field ' + tableName + '.' + fieldName + ' not found');
    return false;
}

// Usage in migration script
if (fieldExists('incident', 'u_custom_priority')) {
    // Safe to proceed with migration
}

Count fields by type across all active tables

// Platform health check - field type distribution
var ga = new GlideAggregate('sys_dictionary');
ga.addQuery('active', true);
ga.addNotNullQuery('internal_type');
ga.groupBy('internal_type');
ga.addAggregate('COUNT');
ga.query();

while (ga.next()) {
    var fieldType = ga.internal_type.toString();
    var count = ga.getAggregate('COUNT');
    gs.print(fieldType + ': ' + count + ' fields');
}

Wrong way vs right way to find choice fields

// WRONG: This misses choice fields that use choice lists
// var gr = new GlideRecord('sys_dictionary');
// gr.addQuery('reference', 'CONTAINS', 'choice');

// RIGHT: Check internal_type for reliable field type detection
var gr = new GlideRecord('sys_dictionary');
gr.addQuery('name', 'STARTSWITH', 'incident.');
gr.addQuery('internal_type', 'choice');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    // Now you have actual choice fields, not reference fields
    gs.print(gr.element + ' uses choice list: ' + gr.reference);
}

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_dictionary