Field Types & Data Dictionary

Section 1

The Data Dictionary

The Data Dictionary is the master catalog of every field on every table in ServiceNow. It lives in the sys_dictionary table. Every field you see on a form — the short description on an Incident, the priority dropdown, the assignment group reference — has a corresponding record in sys_dictionary that defines it.

That dictionary record specifies: what type of data the field holds, whether it is mandatory, its maximum length, its display label, its default value, and many other properties. When ServiceNow renders a form, it reads the dictionary to know what controls to display. When an API call updates a field, the dictionary defines what values are valid.

💡

Analogy — The Field Rulebook Think of the Data Dictionary as a rulebook for every column in every spreadsheet in ServiceNow. For each column it says: "this is a number field, maximum 9 digits, mandatory, default value is 0." Whenever anyone tries to put data into that column — via form, API, or import — ServiceNow checks the rulebook first.

Navigating the Dictionary

Go to System Definition → Dictionary in the Application Navigator. You can filter by table name to see all fields on a specific table. Each row is a field definition showing the table name, column name, type, label, and attributes.

Alternatively, right-click any column header in a list view and select Configure Dictionary to jump directly to that field's dictionary entry. On a form, right-click a field label and choose Configure Dictionary for the same shortcut.

Section 2

Core Field Types

ServiceNow field types are far more specific than simple "string" or "integer." Knowing the exact type tells you how the field behaves in forms, reports, scripts, and API calls.

String

Free text up to max_length characters. Used for names, descriptions, short text fields.

Integer

Whole numbers. Used for priority, impact, urgency, count fields. No decimal places.

Boolean

True/false stored as 0 or 1. Rendered as a checkbox on forms.

Reference

Foreign key to another table. Stores sys_id. Displays display_value in UI.

Choice

Drop-down list of predefined values from sys_choice table. Stores the key/value.

GlideDateTime

Date and time. Stored as UTC in database. Displayed in user's local timezone.

Duration

Time span (e.g., "3 days 4 hours"). Used for SLAs and business hours calculations.

Journal

Append-only text log. Work Notes and Comments use Journal fields. Cannot be edited after entry.

URL

Rendered as a clickable hyperlink on forms. Stored as string internally.

List

Multi-value reference list (many-to-many relationship). Watch list uses this type.

Script

JavaScript code stored as text. Used on script fields; rendered in code editor on forms.

Decimal

Numbers with decimal places. Used for financial amounts, percentages.

⚠

Exam Trap — GlideDateTime Storage vs. Display GlideDateTime fields are always stored in UTC in the database. They are displayed in the user's time zone preference. When using the Table API, the value returned is in UTC format unless you use sysparm_display_value=true. Scripts reading GlideDateTime via GlideRecord also return UTC values — convert to local time intentionally, not accidentally.

Section 3

Reference Fields — Foreign Keys in ServiceNow

A Reference field is ServiceNow's version of a foreign key. It links a field on one table to a record on another table. For example, the assigned_to field on an Incident is a Reference field pointing to the sys_user table.

Here is the crucial thing to understand: what the field stores versus what it displays are different. The field stores a sys_id — the unique 32-character identifier of the referenced record. But on the form and in reports, it displays the display value — typically the name of the referenced record.

📘

Core Concept — sys_id vs. Display Value When you see "John Smith" in the Assigned To field, that is the display value. The database actually stores abc123def456... (John Smith's sys_id). When you query via the Table API with sysparm_display_value=false (default), you get the sys_id. With sysparm_display_value=true, you get "John Smith." With sysparm_display_value=all, you get both in the response.

Display Value Configuration

Each table has a display field configured — the field that serves as the "name" when the table is referenced from elsewhere. For sys_user, the display field is name. For incident, it is number. When you configure a Reference field in the dictionary, you specify which table it points to, and ServiceNow automatically uses that table's display field for the label.

⚠

Exam Trap — Searching on Reference Fields When you filter a list on a reference field (e.g., "Assigned to = John Smith"), ServiceNow searches by the display value you see, but stores the sys_id in the filter. If John Smith's user record is deleted, that filter breaks — it stored his sys_id, which no longer resolves to a name. This is why referential integrity matters in CMDB data.

Section 4

Choice Lists

A Choice field presents a drop-down list of options on the form. The options are defined in the sys_choice table — one record per choice option. Each choice has a label (what users see) and a value (what is stored in the database). These are often different.

For example, the State field on an Incident has the label "New" displayed to users, but stores the value 1 in the database. "In Progress" displays but stores 2. "Resolved" displays but stores 6. When you write a business rule condition checking current.state == 6, you are using the stored value, not the displayed label.

⚠

Exam Trap — Labels vs. Values in Conditions Business Rules, Client Scripts, and Workflows must use the stored value when checking choice fields — not the display label. Writing current.state == 'Resolved' will NOT work because Resolved stores as 6. Use current.state == 6. The exam frequently tests this distinction.

Dependent Choice Lists

Dependent choice lists filter one field's options based on the value of another field. For example, the Sub-category field's options change based on which Category is selected. This is configured by setting the Dependent field on the choice list entry — pointing to the parent field that controls which choices appear.

Section 5

Dictionary Overrides

Here is a critical concept unique to ServiceNow's inheritance model. When Table B extends Table A, Table B inherits all of Table A's fields. But what if you need a field to behave slightly differently on Table B than on Table A? For example, you might want the priority field to be mandatory on incident but optional on other task subtypes. The answer is a Dictionary Override.

A Dictionary Override creates a child-table-specific entry in sys_dictionary for an inherited field. You can override: mandatory, read-only, default value, max length, and calculated properties — without touching the parent table's definition.

📘

Core Concept — Override Without Breaking Inheritance Dictionary Overrides let you customize inherited field behavior per child table while preserving the parent field definition. The parent table still sees its original definition. Only the child table with the override behaves differently. This is how incident can make priority mandatory while change_request leaves it optional — both inherit the same field, but one has an override.

⚠

Exam Trap — Override vs. Changing Parent To change a field's behavior on only one child table, use a Dictionary Override. Changing the parent dictionary entry itself affects ALL tables that inherit it. The exam will present a scenario like "make this field mandatory on incidents only" — the correct answer is Dictionary Override, not editing the parent field.

Section 6

Default Values & Calculated Fields

Every field in the dictionary can have a default value that pre-populates the field when a new record is created. Default values can be static (a specific string, number, or choice value) or dynamic (a JavaScript expression that runs at creation time).

A calculated field (also called a "derive" or "virtual" field) automatically computes its value from other fields using a script. You define a JavaScript expression in the dictionary entry that runs whenever the record is loaded or saved. Calculated fields are read-only on the form — users cannot manually set them.

Feature	Default Value	Calculated Field
When it runs	Only on new record creation	Every time record loads or saves
User can override?	Yes — user can change it	No — always derived from script
Stored in DB?	Yes — stored after user saves	Depends on "Store value" setting
Script required?	Optional (can be static)	Yes — always a script
Example	State defaults to "New" (1)	Priority auto-calculated from impact × urgency

💡

Tip — Priority Auto-Calculation The classic example of a calculated field is priority on Incident. It is automatically derived from the combination of impact and urgency values using a priority lookup matrix. This is why changing impact or urgency on a live incident automatically updates the priority without the user touching the priority field.

Exam Quick Reference

Common Exam Traps — Field Types & Dictionary

sys_dictionary is the table that stores all field definitions
Reference fields store sys_id internally — display value (name) is looked up separately
sysparm_display_value=true returns labels; =false (default) returns raw values; =all returns both
Choice fields store the value (e.g., 1), not the label (e.g., "New") — business rule conditions use values
GlideDateTime is always stored in UTC; displayed in user's local timezone
Dictionary Overrides let you change a field's behavior on a child table without affecting the parent or siblings
Journal fields (Work Notes, Comments) are append-only — existing entries cannot be edited or deleted
Calculated fields are read-only on the form — they derive their value from a script automatically

Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Field Types Quiz 1 / 4

A REST API call to the ServiceNow Table API returns a reference field value of 6abb3945db4b13009e6e3d4e0f9619b6. What does this value represent?

💡 Explanation

B is correct. Reference fields store the sys_id of the referenced record internally. The 32-character hex string is a sys_id. To get the display name, you must either dot-walk or pass sysparm_display_value=true. A is wrong because that would require sysparm_display_value=true. C and D are incorrect.