Reference Fields and Relationships

Reference Fields and Relationships in ServiceNow CAD

Reference Fields and Relationships in ServiceNow

Why Is This Important?
Reference fields and relationships are fundamental building blocks in ServiceNow application design. They define how tables connect to one another, enabling data integrity, efficient navigation, and meaningful reporting across the platform. For the ServiceNow Certified Application Developer (CAD) exam, understanding reference fields and relationships is critical because they appear in questions about data modeling, application design, scripting, and system behavior. A solid grasp of this topic ensures you can design robust applications and answer a wide range of exam questions confidently.

What Are Reference Fields?
A reference field is a field type in ServiceNow that creates a relationship between two tables by storing the sys_id of a record on another table. When you create a reference field on a table, you are essentially creating a foreign key relationship.

For example, the Incident table has a reference field called Caller that references the User (sys_user) table. The actual value stored in the database is the sys_id of the user record, but the display value shown to the user is typically the user's name.

Key Characteristics of Reference Fields:
- Store a sys_id (32-character GUID) pointing to another table's record
- Provide a lookup icon (magnifying glass) for users to search and select related records
- Support dot-walking, which allows you to traverse relationships to access fields on related tables (e.g., incident.caller_id.email)
- Automatically create a one-to-many (1:M) relationship between the referenced table and the current table
- Can be configured with reference qualifiers to limit the records available for selection

What Are Relationships in ServiceNow?
ServiceNow supports several types of relationships between tables:

1. One-to-Many (1:M) Relationships
This is the most common relationship type, automatically created when you add a reference field. One record on the referenced table can be associated with many records on the table containing the reference field.
- Example: One User can be the caller on many Incidents.

2. Many-to-Many (M:M) Relationships
When records on both tables need to relate to multiple records on the other table, a many-to-many relationship is used. ServiceNow implements this using an intermediary table (a M2M table) that contains two reference fields — one pointing to each of the related tables.
- Example: A User can belong to many Groups, and a Group can contain many Users. The sys_user_grmember table serves as the M2M table.

3. One-to-One (1:1) Relationships
These are less common and are typically implemented using a reference field where uniqueness is enforced, or through table extensions.

4. Database Views
Database views allow you to join two tables together to create a virtual table for reporting and display purposes without creating new physical tables. They are read-only and useful for combining related data from different tables.

How Reference Fields Work in Detail

Dot-Walking:
One of the most powerful features of reference fields is dot-walking. This allows you to traverse the reference relationship to access fields on the referenced record without additional queries.
- In a script: var email = current.caller_id.email;
- In a condition builder: You can select Caller → Email to filter or display values from the referenced User record.
- In notifications: You can use dot-walking in mail scripts and templates.

Important: Dot-walking works across multiple levels (e.g., incident.caller_id.department.name), but excessive dot-walking can impact performance.

Reference Qualifiers:
Reference qualifiers restrict which records appear in the reference field lookup. There are several types:
- Simple qualifier: A fixed encoded query (e.g., active=true)
- Dynamic qualifier: Uses javascript: prefix to run a script that returns an encoded query
- Advanced reference qualifiers: Can use scripted conditions based on current form values

Example of a dynamic reference qualifier:
javascript:'company=' + current.company

Display Values vs. Actual Values:
- The actual value stored in the database for a reference field is the sys_id of the referenced record.
- The display value is determined by the display field configured on the referenced table (typically the Name or Number field).
- In scripting, getValue() returns the sys_id, while getDisplayValue() returns the display value.

Related Lists:
When a reference field is created, ServiceNow can automatically display a related list on the referenced table's form showing all records that reference it. For example, the User form can show a related list of all Incidents where that user is the caller.

Glide List Fields:
A Glide List is a field type that allows you to store multiple references to records on another table in a single field. It stores a comma-separated list of sys_ids. This is different from a standard reference field, which stores only one sys_id.
- Example: The Watch list field on the Task table is a Glide List referencing sys_user.

How to Create Reference Fields and Relationships

Creating a Reference Field:
1. Navigate to the table's dictionary or use the form designer/table builder.
2. Add a new field and set the type to Reference.
3. Specify the reference table (the table you want to point to).
4. Optionally set a reference qualifier to filter available choices.
5. Save the record.

Creating a Many-to-Many Relationship:
1. Navigate to System Definition → Many to Many Definitions or use the related links on a table's definition.
2. Specify the two tables involved in the relationship.
3. ServiceNow automatically creates the intermediary (M2M) table with two reference fields.
4. Related lists are added to both tables' forms to display the relationship.

Scripting with Reference Fields

When working with reference fields in server-side scripts:
- current.caller_id returns a GlideElement object (not a simple string).
- current.getValue('caller_id') returns the sys_id as a string.
- current.caller_id.getDisplayValue() returns the display value.
- current.caller_id.name uses dot-walking to get the name field from the referenced user record.
- To set a reference field, assign a sys_id string: current.caller_id = 'sys_id_value';

In client-side scripts:
- g_form.getValue('caller_id') returns the sys_id.
- g_form.getDisplayValue('caller_id') returns the display value.
- g_form.getReference('caller_id', callback) retrieves the full referenced record asynchronously (GlideAjax call behind the scenes).

Exam Tips: Answering Questions on Reference Fields and Relationships

1. Know What a Reference Field Stores: Always remember that reference fields store a sys_id, not a display value. This is one of the most commonly tested concepts. If a question asks what value is stored in the database for a reference field, the answer is the sys_id.

2. Understand Dot-Walking Thoroughly: Expect questions about accessing related data via dot-walking in scripts, conditions, and notifications. Know that dot-walking is possible in server-side scripts, conditions, and reports. Understand the syntax and limitations.

3. Differentiate Between getValue() and getDisplayValue(): Questions may present code snippets and ask what the output will be. getValue() on a reference field returns the sys_id; getDisplayValue() returns the human-readable display value.

4. Reference Qualifiers Are Key: Know the difference between simple, dynamic, and advanced reference qualifiers. Be prepared to identify the correct syntax for a dynamic reference qualifier using the javascript: prefix.

5. Know M:M Relationship Implementation: If asked how to implement a many-to-many relationship, the answer involves creating a Many to Many Definition (or an intermediary table with two reference fields). ServiceNow does not natively support M:M through a single reference field.

6. Glide List vs. Reference Field: Know that a Glide List stores multiple sys_ids in a single field (comma-separated), while a standard reference field stores exactly one sys_id. Questions may test whether you can distinguish between these two field types.

7. Related Lists and Relationships Module: Understand that related lists are driven by reference fields. Also know the Relationships module (sys_relationship) which allows you to define custom related lists using scripts — this is different from the standard reference-driven related lists.

8. Table Extension and Inheritance: Reference fields on a parent table (e.g., Task) are inherited by child tables (e.g., Incident, Change Request). Understand how table hierarchy works in conjunction with reference fields.

9. Performance Considerations: While not heavily tested, be aware that excessive dot-walking (especially in list views or reports across many levels) can impact performance. Use GlideRecord queries judiciously.

10. Read the Question Carefully: Many reference field questions are scenario-based. Pay attention to whether the question asks about the stored value, the displayed value, or the behavior of the field. Also look for keywords like "filter," "restrict," or "limit" — these often point to reference qualifiers.

11. Practice with Real Scenarios: If possible, practice creating reference fields in a Personal Developer Instance (PDI). Create reference qualifiers, test dot-walking in business rules, and build M:M relationships. Hands-on experience solidifies these concepts more effectively than memorization alone.

Summary
Reference fields are the backbone of data relationships in ServiceNow. They store sys_ids, enable dot-walking, and support related lists. Understanding how to create, configure (with reference qualifiers), and script with reference fields — along with knowing the difference between 1:M and M:M relationships — will prepare you to handle a significant portion of the CAD exam questions on application design and data modeling.