Table Relationships

Table Relationships in ServiceNow

Why Table Relationships Are Important

Table relationships form the backbone of ServiceNow's data architecture. Understanding how tables connect to each other is essential for building effective applications, creating accurate reports, and navigating the platform efficiently. For CSA exam candidates, this topic is critical because it appears frequently in questions about data management, reporting, and application development.

What Are Table Relationships?

Table relationships define how records in one table connect to records in another table. ServiceNow uses a relational database structure where tables can be linked through specific field types and inheritance models.

Types of Table Relationships:

1. Reference Fields (One-to-Many)
A reference field in one table points to a record in another table. For example, the Incident table has a reference field called 'Caller' that points to the User table. One user can have many incidents, but each incident has one caller.

2. Glide List Fields (Many-to-Many)
Glide list fields allow a single record to reference multiple records from another table. For example, a Knowledge Article might have multiple categories assigned to it.

3. Table Extension (Parent-Child Inheritance)
Child tables inherit fields and business logic from parent tables. The Task table is extended by Incident, Problem, Change Request, and other tables. All child tables inherit the fields and configurations of the Task table.

4. Document ID Fields
These special reference fields can point to records in any table, providing flexible relationships across the platform.

How Table Relationships Work

Reference Field Mechanics:
When you create a reference field, ServiceNow stores the sys_id of the referenced record. This creates a link between the two tables that can be followed in either direction using dot-walking notation.

Dot-Walking:
Dot-walking allows you to traverse relationships to access fields from related tables. For example, incident.caller_id.manager.email walks from the incident to the caller, then to their manager, and retrieves the manager's email address.

Table Hierarchy:
Extended tables form a hierarchy. The base system table is sys_metadata. Application tables often extend from Task [task]. When querying a parent table, you can include records from child tables by enabling the 'Include children' option.

Common Table Relationships in ServiceNow

- Task is extended by Incident, Problem, Change Request, Request, and Requested Item
- Configuration Item [cmdb_ci] is extended by Computer, Server, Network Gear, and Application
- User [sys_user] is referenced by many tables for assignment, caller, and opened_by fields
- Group [sys_user_group] is referenced for assignment groups across task-based tables

Exam Tips: Answering Questions on Table Relationships

Tip 1: Know the Table Hierarchy
Memorize that Task is the parent table for Incident, Problem, Change, and Request. Questions often test whether you understand inheritance.

Tip 2: Understand Reference vs. Glide List
Reference fields create one-to-many relationships, while Glide List fields create many-to-many relationships. Know when each is appropriate.

Tip 3: Master Dot-Walking Syntax
Expect questions about accessing related data. Remember that dot-walking follows reference fields to retrieve data from connected tables.

Tip 4: Recognize Extended Table Behavior
Child tables inherit all fields, business rules, and UI policies from parent tables. Any customization on a parent table affects all its children.

Tip 5: Watch for Trick Questions
Some questions may present scenarios where relationships seem complex. Break them down by identifying which table extends which, and which fields are references.

Tip 6: Remember the sys_id Connection
All reference relationships are based on sys_id values. This unique identifier is how ServiceNow links records across tables.

Practice Scenario
If asked how to display the department of an incident's assigned user, recognize that you need to dot-walk: incident.assigned_to.department. This traverses from Incident to User to Department.