5.1 Data Model & Tables

Why the Data Model Matters for the CSA Exam

Database Management and Platform Security is the largest single domain on the ServiceNow Certified System Administrator (CSA) exam at roughly 30% of scored questions. Almost every other platform feature — Access Control Lists, business rules, reports, and the service catalog — sits on top of the data model. If you understand how tables, fields, and the Dictionary work, the rest of the platform becomes far easier to reason about.

ServiceNow runs on a single relational database per instance. Everything you see in the interface — an incident, a user, a knowledge article, even a system property — is a row in a table. There are no separate files or spreadsheets behind the scenes.

Tables and Columns

A table is a collection of records of the same type. A column (called a field in the user interface) is a single attribute stored for every record in that table. ServiceNow table names use a category prefix you should recognize on the exam:

Every record automatically receives system fields including a globally unique sys_id (a 32-character identifier), sys_created_on, sys_created_by, sys_updated_on, and sys_updated_by. The sys_id, not the display value, is how ServiceNow uniquely identifies a record internally.

The Dictionary (sys_dictionary)

The Data Dictionary is the metadata catalog that defines every table and every field. Each row in the sys_dictionary table describes one column: its type (String, Integer, Reference, Choice, Date/Time, True/False, and so on), maximum length, default value, whether it is mandatory or read-only, and dictionary attributes. The related sys_documentation table stores the human-readable labels and hints. To change how a field behaves platform-wide, you change its dictionary entry — not the data itself.

Table Extension: Class and Parent-Child Hierarchies

ServiceNow supports table extension, where a child table extends a parent table and inherits all of the parent's fields. This creates an object-oriented class hierarchy.

The classic example is the Task hierarchy:

task
 ├── incident
 ├── problem
 ├── change_request
 └── sc_task

Key rules to memorize for the exam:

• A child table inherits every field defined on the parent, then adds its own.
• Parent and child records share one physical storage structure; querying the parent (task) returns records from all child tables.
• The sys_class_name field stores the actual class (table) of each record, which is how one base table can hold multiple specialized types. This pattern is also called table-per-class with a discriminator.
• Extending a table is permanent in practice — you cannot cleanly "un-extend" once data exists.

CMDB Basics

The Configuration Management Database (CMDB) is ServiceNow's model of the IT environment. Every Configuration Item (CI) table extends the base cmdb_ci table. cmdb_ci itself extends cmdb, and specialized classes such as cmdb_ci_computer, cmdb_ci_server, and cmdb_ci_database extend down the tree. Because every CI shares the cmdb_ci base, you can report on or apply security to all CIs at once while still modeling each class precisely. Relationships between CIs (for example Runs on or Depends on) are stored separately in the cmdb_rel_ci table, not as fields on the CI itself.

Reference Fields vs. Glide List Fields

Both field types connect one record to others, but they behave very differently and the CSA exam tests the distinction.

A Reference field points at a single record on a referenced table (defined in the dictionary as the Reference attribute). For example, incident.caller_id references a row in sys_user. A Glide List (also called a List field) is effectively a multi-reference field that holds many sys_id values to the same target table — the watch_list field on Incident is the canonical example.

Choice Fields

A Choice field restricts input to a predefined list of values stored in the sys_choice table. Examples include Incident state, priority, and impact. Choices have a label (shown to users) and a value (stored in the database, often a number or short code). The dictionary Choice attribute controls behavior: Dropdown without --None--, Dropdown with --None--, Suggestion, or None (free text). Knowing that the stored value differs from the displayed label is a frequent exam point.

Schema Map and Table Relationships

The Schema Map is a graphical tool (System Definition > Tables, or the Schema Map module) that visualizes a table, its parent (extension) relationships, and its referenced/referenced-by tables. It is the fastest way to see how Incident connects to User, Group, CMDB, and the Task hierarchy. The related Table Relationship diagram and the Tables and Columns module give the same information in list form.

Dot-Walking

Dot-walking is the technique of following a Reference field to read fields on the related record using dot notation. On the Incident table:

• caller_id.email returns the caller's email address.
• caller_id.department.name walks two references: Incident → User → Department.
• assignment_group.manager.name returns the manager of the assigned group.

Dot-walking works in filters, list columns, reports, business rules, and ACL conditions. It only follows Reference (and similar single-pointer) fields — you cannot dot-walk through a plain String field, because a String does not point at another record. This is why field type design directly affects what you can build later.