Relationships & Database Views

Section 1

One-to-Many: Reference Fields

The most common relationship type in ServiceNow is one-to-many, implemented via a Reference field. One record on the "one" side is referenced by many records on the "many" side. The relationship is stored as a sys_id in the Reference field on the "many" side's table.

Example: one sys_user (person) can be the caller_id on many Incidents. The caller_id field on the incident table is a Reference field pointing to sys_user. Each Incident stores one caller's sys_id. That user record has no "list of incidents they reported" field — you get that by querying Incidents where caller_id = [user sys_id].

💡

Analogy — Address on an Envelope A Reference field is like writing someone's address on an envelope. The envelope (incident) contains the address (sys_id pointing to the person). Many envelopes can have the same address, but each envelope holds only one address. To find all envelopes going to the same address, you search by that address.

Related Lists

When you open a record that other records reference, ServiceNow can show you those related records in Related Lists at the bottom of the form. For example, when you open a User record, the Related Lists section shows all Incidents where that user is the caller. This is just a filtered query — not a separate stored relationship.

Section 2

Many-to-Many: M2M Tables

Sometimes a record on Table A can relate to multiple records on Table B, AND a record on Table B can relate to multiple records on Table A. This is a many-to-many (M2M) relationship. You cannot implement this with a single Reference field — you need a dedicated junction table (also called an M2M table or relationship table).

The M2M table has exactly two Reference fields: one pointing to Table A and one pointing to Table B. Each row in the M2M table represents one link between one record from A and one record from B.

📘

Core Concept — M2M Pattern Example A User can belong to multiple Groups. A Group can have multiple Users. Neither a single Reference field on sys_user nor one on sys_user_group can express this. The solution is the M2M table sys_user_grmember — it has a user Reference field and a group Reference field. Each row says "User X is a member of Group Y." One user maps to many rows; one group maps to many rows.

Common M2M Tables in ServiceNow

M2M Table	Left Side	Right Side	Meaning
sys_user_grmember	sys_user (user)	sys_user_group (group)	User is member of Group
task_ci	task	cmdb_ci	Task affects this CI
cmdb_rel_ci	cmdb_ci (parent)	cmdb_ci (child)	CI has relationship with CI
sys_user_has_role	sys_user	sys_user_role (role)	User is directly assigned a role (sys_user_role is the role definition table, not the junction)

⚠

Exam Trap — cmdb_rel_ci Is Self-Referential M2M The cmdb_rel_ci table is an M2M table where BOTH reference fields point to cmdb_ci — it links a CI to another CI. It has a third field, type, which defines the relationship type (e.g., "Runs on," "Depends on," "Hosted on"). This pattern is how ServiceNow models CI dependency relationships.

Section 3

Database Views — Joining Tables for Reporting

A Database View is a virtual, read-only "table" that presents a JOIN of two or more real tables as if they were one. You navigate to System Definition → Database Views to create one.

To create a Database View, you specify:

Primary table — the main table (e.g., incident)
Join table(s) — the additional table(s) to join (e.g., cmdb_ci)
Join condition — how to match rows (e.g., incident.cmdb_ci = cmdb_ci.sys_id)
Fields — which fields from each table to expose in the view

Once created, the view appears as a "table" in the report builder. Users can build reports that show Incident fields alongside the CI fields of the affected configuration item — without needing to understand the JOIN logic themselves.

⚠

Exam Trap — DB View Performance Database Views execute a JOIN query at report run time. On large tables, this can be significantly slower than reporting on a single indexed table. The exam may ask about performance trade-offs — Database Views are powerful but expensive. For very large datasets, consider Performance Analytics or pre-aggregated data instead.

Section 4

Dynamic Reference Qualifiers

A Reference Qualifier filters which records can be selected in a Reference field. Without a qualifier, a Reference field to sys_user lets you pick any active user. With a qualifier, you could restrict it to "only users in the ITSM team" or "only users with the itil role."

There are three types of Reference Qualifiers:

Static — a fixed encoded query that never changes (e.g., active=true^department=IT)
Dynamic — an encoded query that includes variables resolved at run time (e.g., uses current user's department)
Scripted — a JavaScript function that returns a GlideRecord or encoded query — maximum flexibility

💡

Tip — Qualifiers Are Client-Side Only Reference qualifiers only filter the picker dialog — they don't enforce a data constraint. A user can still type a sys_id directly into an API call or import that bypasses the qualifier. To truly enforce what values are valid, use a Business Rule or Data Policy in addition to the qualifier.

Principal Class Filtering (CMDB-Specific)

Principal Class Filtering is a special CMDB mechanism that restricts which CI class can be selected in a Reference field pointing to cmdb_ci. Without it, any Reference field to cmdb_ci lets you pick any CI of any class. With Principal Class Filtering, you can restrict it to "only pick from cmdb_ci_server" or "only pick from cmdb_ci_database."

This is configured on the dictionary entry for the Reference field. Navigate to the field's dictionary entry, open the Reference Specification related list, and add a Principal Class record specifying which CI class(es) are valid selections. This is commonly used on tables like Change Requests where you want to enforce that the "Configuration Item" field only accepts CIs of a specific type.

⚠

Exam Trap — Principal Class Filtering Scope Principal Class Filtering only restricts which class is selectable in the UI picker. It does NOT prevent a sys_id from a different class being stored via script or API. For strict enforcement, combine Principal Class Filtering with a server-side Business Rule.

Section 5

Relationship Types Summary

Pattern	Implementation	Storage	Example
One-to-Many	Reference field on "many" table	sys_id stored on "many" side	Incident → User (caller_id)
Many-to-Many	Junction/M2M table with two Reference fields	Each pair = one row in M2M table	User ↔ Group (sys_user_grmember)
Parent-Child (hierarchy)	Reference to same table (self-join)	parent field on task table	sc_req_item.request → sc_request
CI Relationships	Self-referential M2M (cmdb_rel_ci)	parent, child, type fields	Server "Runs on" Rack
Cross-table Reporting	Database View (virtual JOIN)	No extra storage — computed	Incident + CI fields in one report

Exam Quick Reference

Common Exam Traps — Relationships & DB Views

Reference fields implement one-to-many — the field stores the sys_id of the referenced record
Many-to-many relationships require a junction/M2M table — never a Reference field alone
cmdb_rel_ci is the M2M table for CI-to-CI relationships; it has a type field for the relationship kind
Database Views are read-only — created for reporting only, cannot insert/update data
Reference Qualifiers filter the picker UI only — they don't enforce constraints on API or script inserts
Principal Class Filtering restricts which CI class can be picked in a Reference field on CMDB tables
Related Lists on forms are query-based — not a stored field, but a live filtered query result

Exam Checkpoint

Practice Questions

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

Relationships Quiz 1 / 4

A CI-to-CI many-to-many relationship needs to be modeled in ServiceNow. What is the correct approach?

💡 Explanation

B is correct. cmdb_rel_ci is the standard M2M junction table for CI-to-CI relationships. Each row links a parent CI to a child CI via a relationship type. A (Reference field) only supports one-to-many. C (Database View) is read-only and doesn't store relationship data. D (list field) is not a recognized relationship model and doesn't integrate with impact analysis.