Tables & data model in Getting started

Tables & data model

Everything in ServiceNow is a record in a table, master this and the rest clicks.

Quick answer

ServiceNow is, at heart, a relational database with a workflow engine and UI on top. Every incident, user, CI, catalog item and even every configuration record is a row in a table.

Key takeaways

Core vocabulary
Table extension, the Task hierarchy
Field types that matter
References and dot-walking
The dictionary and attributes

ServiceNow is, at heart, a relational database with a workflow engine and UI on top. Every incident, user, CI, catalog item and even every configuration record is a row in a table. Master the data model, tables, fields, the dictionary, table extension, references and dot-walking, and the rest of the platform stops being a collection of features and becomes one coherent system.

Core vocabulary

Table

A collection of records (rows). Has a label ("Incident") and an internal name (incident), scripts use the internal name.

Record

One row, one incident, one user.

Field / column

A typed attribute: string, choice, reference, date/time, boolean, integer, journal.

sys_id

The 32-char unique key on every record. All references are stored as sys_ids.

Dictionary

sys_dictionary, the definition of every field: type, length, default, attributes.

Table extension, the Task hierarchy

Tables can extend a parent, inheriting all its fields and adding their own, classic object-oriented inheritance, in the database. The most important example is task:

task  (number, assignment_group, state, priority, short_description)
 +- incident            + caller_id, category, subcategory
 +- problem             + known_error, workaround
 +- change_request      + risk, type, cab_required, start_date
 +- sc_req_item (RITM)  + cat_item, variables
 +- sc_task (SCTASK)    + request_item

This inheritance has real consequences you will use constantly:

A report, business rule or ACL written on task automatically applies to every child.
A reference field of type "Task" can point at an incident or a change, they share the parent type.
Physically, ServiceNow can store extended tables in the parent's table (table-per-hierarchy), which is why task is a huge table.

Field types that matter

String

Text. Watch the max length (default 40 / 255).

Choice

A fixed dropdown backed by sys_choice; stored value is not the display label.

Reference

Stores another record sys_id; displays that record display value.

Glide Date/Time

Timezone-aware; manipulate with GlideDateTime, not strings.

Journal

Append-only work notes / comments, every entry is preserved.

True/False

Boolean checkbox.

References and dot-walking

A reference field stores a sys_id and shows the target display value. Because references chain, you can dot-walk across relationships in filters, reports and scripts without a second query:

// on incident: caller, their department, its head, email
caller_id.department.dept_head.email

// in a filter, the same path is selectable via the arrows
caller_id.vip = true            // incidents raised by VIPs

The display value of a table is set by the field marked "Display" in its dictionary. That is why a reference to a user shows a name, not a sys_id, and why changing which field is the display value changes references everywhere at once.

The dictionary and attributes

Every field is defined in sys_dictionary: its type, length, default value, and attributes (mandatory, read-only, display, and many advanced flags). The dictionary is the ground truth beneath forms, field-level rules like data policies and field ACLs build on top of it. A field made mandatory in the dictionary is mandatory everywhere, unconditionally; that is a bigger hammer than a conditional data policy.

Special table families to recognise

cmdb_ci*

Configuration items, the CMDB; every CI extends cmdb_ci.

sys_user / sys_user_group

People and groups, the access model.

u_imp_* / staging

Import staging tables feeding transform maps.

sys_script, sys_ui_policy

Configuration-as-data: your rules and policies live here.

sys_metadata

The parent of customisable records, what update sets track.

Common mistakes

Confusing the label (what users see) with the internal name (what scripts use).
Comparing a reference field to a display value in a script instead of its sys_id.
Creating a standalone table for a unit of work instead of extending task and inheriting its process.
Ignoring string field max-length and silently truncating imported data.
Over-using dot-walking in hot code where a stored value would be far faster.

Practice challenge

+0 XPStreak ×0

Question 1 of 3

A single row in a table is a:

Frequently asked questions

What does the term Tables & data model refer to in ServiceNow?

ServiceNow is, at heart, a relational database with a workflow engine and UI on top. Every incident, user, CI, catalog item and even every configuration record is a row in a table.

What is the ITSM role of Tables & data model?

A report, business rule or ACL written on task automatically applies to every child. A reference field of type "Task" can point at an incident or a change, they share the parent type.

What else is worth knowing about Tables & data model?

Tables can extend a parent, inheriting all its fields and adding their own, classic object-oriented inheritance, in the database.

What tends to go wrong with Tables & data model?

Confusing the label (what users see) with the internal name (what scripts use). Comparing a reference field to a display value in a script instead of its sys_id. Creating a standalone table for a unit of work instead of extending task and inheriting its process.