ServiceNow Reference Fields

Reference fields are the connective tissue of ServiceNow. They link records across different tables, letting the platform relate a ticket to a user, a user to a department, or an asset to a location. Without reference fields, data would sit in disconnected silos with no relationships between them.

What Is a Reference Field?

A reference field stores a pointer to a record in another table. On screen, it displays a readable value — usually the name of the linked record. Behind the scenes, it stores that record's sys_id (the unique 32-character identifier).

Incident Form: "Assigned To" field (Reference)
┌──────────────────────────────────┐
│ Assigned To: [John Smith    🔍]  │
└──────────────────────────────────┘
         │
         └──► Points to User Record in sys_user table
                   sys_id: 8c3b1f9a3c3b1f9a...
                   name: John Smith
                   email: john.smith@company.com
                   department: IT

How Reference Fields Work on a Form

A reference field on a form shows a text box with a magnifying glass icon. Users type a name to search or click the magnifying glass to open a reference lookup popup. The popup lists records from the target table. Selecting a record fills the reference field and stores its sys_id.

Reference Qualifiers

Administrators restrict which records appear in the reference lookup using a reference qualifier. For example, the "Assignment Group" field only shows active groups, not all groups. A reference qualifier is a filter condition applied to the lookup results to show only relevant options.

Without qualifier:      All 500 groups appear in the lookup
With qualifier          Only the 12 active IT groups appear
(active=true AND
 type=itil):

Dot-Walking: Reading Data Across References

Dot-walking is one of ServiceNow's most powerful features. It lets you read data from a referenced record using dot notation — crossing table boundaries in one step.

Example: Incident references Caller, Caller references their Manager

Incident.caller_id.manager.email

Step by step:
  incident.caller_id       → Goes to the User record of the caller
  .manager                 → From that user, goes to their manager's User record
  .email                   → Gets the manager's email address

Dot-walking works in scripts, conditions, email notifications, and reports. Instead of writing multiple database queries, a single dot-walk expression retrieves deeply nested data in one line.

Dot-Walk in a Business Rule (Script)

var managerEmail = current.caller_id.manager.email.toString();
gs.log("Manager email: " + managerEmail);

Dot-Walk in a Condition Builder

The condition builder in lists and filters supports dot-walking through a visual interface. Click a reference field, then click the arrow that appears to traverse into the referenced table's fields. Chain multiple traversals to reach nested data without writing code.

Reference Fields vs. List Collector Fields

A reference field links to exactly one record. A list collector field links to multiple records from the same table. For example, a "Watchers" field on a change request uses a list collector so multiple users can watch one change — not just one person.

Reference Field:    Assigned To = [John Smith]       ← one person only
List Collector:     Watchers = [Sarah Lee, Mike P., Ana K.] ← multiple people

Display Value vs. Stored Value

This distinction causes confusion for new developers. A reference field displays a name to the user but stores a sys_id in the database. When writing scripts, you must access the right value depending on what you need.

In a Script:

current.assigned_to           → Returns the sys_id (e.g., "8c3b1f9a...")
current.assigned_to.toString() → Returns the sys_id as a string
current.getDisplayValue('assigned_to') → Returns "John Smith"

Wrong approach (common mistake):
if (current.assigned_to == "John Smith") ← NEVER works
                                          (compares sys_id to a name)

Correct approach:
if (current.assigned_to.name == "John Smith") ← dot-walk to .name field

Cascading Reference Fields

Administrators configure one reference field to filter based on another. This is called a dependent reference or cascading field. For example, selecting "Hardware" in the Category field automatically filters the Sub-Category field to show only hardware-related sub-categories. This reduces user errors and speeds up data entry.

Reference Fields in Reports

When building reports, reference fields support dot-walking to pull data from linked tables. A report on incidents can display the caller's department by dot-walking through Caller → Department without any custom coding. ServiceNow's report builder handles the dot-walk automatically when you select a reference field and expand it.