CodeVerse Creatives
Esc
ServiceNow Syllabus / Module 2 of 25 / Week 2

Week 2: Data Model Deep Dive: Dictionary, Extended Tables & Relationships

Every script you write from here on is reading or writing fields defined by a table's dictionary. Getting fluent in how tables extend each other, how reference fields link records together, and how to dot-walk across those links turns every later Glide API call from memorized syntax into something you can actually reason about.

Module 2 of 25 Week 2 of 26 ~3–4 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Explain the task table hierarchy and why incident, problem and change all extend it
  • Read a dictionary entry and identify a field's type and reference target
  • Dot-walk across reference fields and use related lists to navigate connected records
1 The task Hierarchy 2 Dictionary & Field Types 3 Reference Fields 4 Dot-Walking 5 Exercise 6 Knowledge Check

1. The task Table Hierarchy

ServiceNow ships a table called task that holds fields common to "a unit of work someone needs to act on" — state, priority, assignment group, assigned to, opened/closed timestamps. incident, problem, change_request, and sc_task all extend task, inheriting every one of those fields for free and adding their own on top.

conceptual hierarchy
task
├── incident
├── problem
├── change_request
└── sc_task   (Catalog Task, generated from a request)

This matters practically: a script written against task fields (like a Business Rule checking state changes) can, if placed correctly, apply to incidents, problems and changes alike — extension is how ServiceNow avoids reimplementing "assignment" and "state" logic four separate times.

2. Dictionary Entries & Field Types

Every field on every table has a corresponding row in the Dictionary (sys_dictionary) describing its type, length, default value, and — for reference fields — what table it points to. Open any field's dictionary entry (right-click a form label → "Configure Dictionary") and you're looking at the exact metadata the platform used to generate that field's form widget.

  • String / Integer / Boolean / Date-Time — the familiar primitives.
  • Choice — a constrained list of values (like incident.state: New, In Progress, Resolved…), backed by the sys_choice table.
  • Reference — a foreign key to another table's sys_id, covered next.

3. Reference Fields

A reference field (like incident.caller_id, pointing at sys_user) stores the target record's sys_id, not a display name. What renders on the form — a name, an autocomplete search — is the platform resolving that reference at display time using the target table's configured display field.

Reference fields, not foreign key constraints

Unlike a strict SQL foreign key, ServiceNow reference fields don't hard-block you from ever having an orphaned sys_id (a deleted target record, for instance) — the platform handles this gracefully in most UI, but it's a real edge case scripts sometimes need to guard against with a null check after dot-walking.

4. Dot-Walking & Related Lists

Dot-walking is following a reference field across tables using dot notation — in a list view's column configuration, in a condition builder, or in a script. incident.caller_id.department.name reads "on this incident, follow caller_id to the user, then department to the department record, then read its name field" — three tables crossed in one expression.

dot-walking in a script (preview — full GlideRecord API in Week 4)
var callerDept = current.caller_id.department.name;
gs.info('Caller department: ' + callerDept);

Related lists are the form-level equivalent: a panel at the bottom of a record showing rows from a different table that reference this one — an incident's related list of catalog tasks, for example, is really just "every sc_task row whose parent reference points back at this incident's sys_id."

5. Hands-on Exercise

Hands-on

Trace a field back through the data model

Practice reading dictionary metadata instead of guessing at it.

Requirements:

  1. Open any incident record and right-click the "Assigned to" label → Configure Dictionary. Note the field's type and reference table.
  2. In a list view of incident.list, add a column via dot-walking: right-click a column header → "Configure > List Layout" and add Assigned to > Manager > Name.
  3. Open sys_db_object.list, find problem, and confirm what table it extends.
  4. On any incident with related problems, locate the "Problem" related list and open one of the linked problem records.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

Why do incident, problem, change_request and sc_task all extend the task table?

They all represent "a unit of work someone needs to act on" and share common fields — state, priority, assignment group, assigned to. Extending task means those fields, and any logic written against them, only need to be defined once instead of duplicated across every work-item table.

Q2

What does a reference field actually store — a name, or something else?

It stores the target record's sys_id (its GUID), not a display name. Whatever human-readable text you see on a form or list is resolved from that sys_id at display time using the target table's configured display field.

Q3

What does dot-walking let you do that a plain field read can't?

It lets you follow a chain of reference fields across multiple tables in one expression — for example incident.caller_id.department.name crosses from the incident table to sys_user to the department table to read a name three tables away, without writing a separate query for each hop.

Q4

How is a related list on a form different from a regular field on that same form?

A related list isn't stored on the current record at all — it's a live query against a different table, filtered to rows whose own reference field points back at the current record's sys_id. An incident's related Problem list, for instance, is really "every problem record referencing this incident," not data stored on the incident itself.

← Back to Week 1 Up next Week 3 →