Reference fields link records by their identifiers while displaying human-readable values. Display text and stored identity are different.
Before you start
You should understand tables, records and the difference between client-side and server-side scripts. Work in a development instance with representative permissions. Identify execution scope, transaction timing and the current user before attributing behavior to a platform script or business rule.
The practical goal is to reason through this situation: Two users can share a display name while having distinct identifiers. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Read stored identity
The reference value identifies a record independently of its display text.
Step 2: Use display for presentation
Names can change or duplicate across records.
Step 3: Validate target and access
An identifier must refer to an existing permitted record.
Worked scenario
Two users can share a display name while having distinct identifiers.
Two users named Alex appear in a selection list. Updating by display name can affect the wrong one; storing the selected user’s sys_id preserves identity. A display-value comparison is appropriate only when the business question actually concerns display text, not a unique person.
Common mistake
Matching only display text can update the wrong record.
Verify the behavior
Test duplicate names, renamed records and inaccessible referenced users.
Interview exercise
Select a referenced user reliably.
Answer and reasoning
Use the record identifier and validate access and existence, treating the display value as presentation rather than identity.
Continue learning
Compare the scenario with the ServiceNow interview questions and test your understanding with the ServiceNow MCQs. For terminology and implementation details, consult the reference material.