Tables & System Dictionary

What Are Tables?

ServiceNow is fundamentally a database platform. Every piece of data — incidents, users, CIs, knowledge articles, system properties — lives in a database table. Understanding how tables work is the foundation of everything else in the platform.

Tables have columns (fields) and rows (records). To navigate directly to any table's list view, type the table name followed by .list in the Application Navigator filter (e.g., incident.list, sys_user.list).

Tables are themselves records in ServiceNow — every table definition is stored in the sys_db_object table. You can navigate there with sys_db_object.list to see every table in the instance.

Table Naming Conventions

Table names use snake_case (lowercase with underscores). The naming often reflects ownership or grouping:

• sys_ prefix — core system tables (e.g., sys_user, sys_properties)
• sc_ prefix — Service Catalog tables (e.g., sc_request, sc_req_item)
• cmdb_ prefix — Configuration Management DB (e.g., cmdb_ci)
• kb_ prefix — Knowledge Base (e.g., kb_knowledge)
• No prefix — core ITSM tables (e.g., incident, problem, change_request)

Key Tables to Know by Heart

Table Inheritance CRITICAL CONCEPT

ServiceNow uses object-oriented inheritance for tables. A parent table defines base fields shared by all its children. A child table extends the parent, adds its own fields, and automatically inherits every field from the parent.

The Task Inheritance Chain

Why Inheritance Matters Practically

Inheritance has major consequences for security, reporting, and scripting:

The System Dictionary (sys_dictionary)

The System Dictionary is ServiceNow's master catalog of every field on every table. Each row in sys_dictionary defines one column on one table — its data type, constraints, default value, and behavior.

Navigate to it via: System Definition > Dictionary, or type sys_dictionary.list in the navigator filter.

Key Dictionary Field Properties

Creating a New Field (Column)

There are two main methods to add a new field to a table:

1. Navigate to the table's list view by typing tablename.list in the navigator (e.g., incident.list).
2. Right-click any column header in the list and select Configure → Table. This opens the table's field list.
3. Click the New button at the top of the field list to create a new field.
4. Fill in the required properties: Column label, Type, and optionally Column name, Max length, Default value, etc.
5. Save the field definition. The column is now added to the database table.
6. Go to Configure → Form Layout to drag the new field onto the form — it won't appear automatically.

Field Types Reference — Comprehensive

Every dictionary entry has a Type. The type controls the database storage format, the UI input widget displayed on forms, and how values are validated and queried.

Choice Fields & Choice Lists

A Choice field presents users with a fixed dropdown list of options. It is one of the most common field types in ServiceNow, used for fields like State, Category, Impact, Urgency, and Priority.

Choice values are not stored in sys_dictionary — they live in the sys_choice table. Each row in sys_choice represents one option in one dropdown.

Anatomy of a Choice Entry

Value vs Label — Visual Example

Managing Choice Lists

To view or edit the choices for a field:

• Right-click a Choice field on any form → "Show Choice List" — opens sys_choice filtered to that field
• Navigate to sys_choice.list directly and filter by table and element
• From the dictionary record for a Choice field, use the Choices related list at the bottom

Dependent Choice Lists

ServiceNow supports dependent choices — a subset of choices shown based on the value of another field. For example, the subcategory dropdown can show only relevant options depending on what category was selected. This is configured in sys_choice using the Dependent value field on each choice record.

Tables, Forms & Configuration

Form Layout Editor

The Form Layout editor controls which fields appear on a form, their order, and how they are organized into sections. Adding a field to the database does not show it on the form — you must use Form Layout to expose it.

To access Form Layout:

• While viewing a form: right-click the form header → Configure → Form Layout
• Or: right-click any field label → Configure → Form Layout

In the Form Layout editor you can:

• Drag fields from Available (left) to Selected (right) to add them to the form
• Create new collapsible sections to organize fields visually
• Set fields as mandatory at the form level (different from dictionary-level mandatory)
• Arrange fields in a 1-column or 2-column layout per section
• Remove fields from the form without deleting them from the database

Form Views

The same table can have multiple views of its form, each with different fields and layouts. Common built-in views include:

List Layout

Separate from Form Layout, the List Layout controls which columns appear in the list view (tablename.list). Access it via right-clicking a column header → Configure → List Layout. Like Form Layout, list layouts are also per-view.

Script Includes (Brief Overview)

The sys_script_include table stores reusable JavaScript class and function libraries. Script Includes are not fields or forms — they are code modules that can be called from Business Rules, Client Scripts, REST APIs, and other server-side scripts. Each Script Include has a Name (the class/function name), Script (the code), and an API Name used to invoke it.

Quick Reference — Key Navigation Shortcuts