🗄️ ServiceNow — Tables, Data Model & Applications

ServiceNow Developer Guide · Digital Kimya

Everything in ServiceNow is a record in a table.

Diagramme interactif — Hiérarchie des tables

Application Scope — Where Your Code Lives

Every customisation in ServiceNow exists within a scope. The scope determines isolation, access, and portability.

Global Scope

• Default scope for all out-of-the-box (OOB) configurations
• Code in Global can call any other code on the platform
• Customisations in Global are harder to isolate and upgrade-test
• Risk: Global customisations can break on platform upgrades

Scoped Application

• An isolated container for a specific application or feature set
• Has its own tables, scripts, UI components, and access policies
• Cannot call Global-scope scripts without explicit cross-scope access granted
• Prefix applied to all objects: e.g., x_myco_hrapp_leave_request
• Travels cleanly between instances via Update Sets or the App Repo

Example: ServiceNow HR Service Delivery (sn_hr_core) is a scoped app. Its tables, scripts, and ACLs are isolated from the ITSM modules. A custom integration you build as a scoped app (x_acme_sap_integration) can be exported, versioned, and installed independently.

Global Scope
├── incident (table)
├── change_request (table)
└── Custom Business Rule on incident (OOB style — avoid)

Scoped App: x_acme_hr_portal
├── x_acme_hr_portal_leave_request (table)
├── LeaveApprovalUtils (Script Include, scoped)
└── HR Portal Client Scripts

Best practice: New development should always be in a Scoped App, not Global.

The task Table — Foundation of All ITSM

The task table is the parent table for the entire ITSM platform. It defines the common fields shared by every work item in ServiceNow.

Fields Inherited by All Task Children

Because all task children inherit these fields, a GlideRecord query on task returns all incidents, changes, requests, and problems — the entire workload of the platform.

The Task Hierarchy

task (parent — abstract)
├── incident          ← Incident Management
├── problem           ← Problem Management
├── change_request    ← Change Management
├── sc_req_item       ← Service Catalogue (RITM)
│     └── sc_task     ← Catalogue Task (child of RITM)
├── sc_request        ← Catalogue Request wrapper
└── cert_follow_on_task ← ... and many more

incident — Extends task

Incident adds fields specific to disruption management:

State values (Choice List specific to incident):

1 = New
2 = In Progress
3 = On Hold
6 = Resolved
7 = Closed
8 = Cancelled

Note: the state field is inherited from task, but the Choice List values are defined per-table. incident.state = 6 means Resolved. change_request.state = 6 means something completely different.

Service Catalogue — Three-Table Cascade

When a user submits a catalogue request, ServiceNow creates three linked records:

sc_request (REQ)           ← The shopping cart / overall request
  └── sc_req_item (RITM)   ← Each item ordered (extends task)
        └── sc_task (SCTASK) ← Fulfilment tasks created by workflow

Why this matters: SLAs on catalogue requests attach to the RITM, not the REQ. Reporting on catalogue fulfilment should query sc_req_item, not sc_request.

change_request — Extends task

Change adds fields for risk, scheduling, and governance:

Data Dictionary (sys_dictionary)

Every field on every table is defined in the Data Dictionary. This is where you control field types, lengths, defaults, and mandatory flags — not in the table record itself.

Key Dictionary Properties

Adding a custom field via Data Dictionary:

1. Navigate to the table (e.g., open an Incident form)
2. Right-click the form header → Configure → Form Layout
3. Or: navigate to sys_dictionary.list → New
4. Set: Table = incident, Column name = u_business_impact, Type = String, Max length = 200
5. Custom fields always use u_ prefix (not scoped) or x_scope_ (scoped app)

Example — Dictionary query:

// Find all custom fields on the incident table
var dict = new GlideRecord('sys_dictionary');
dict.addQuery('name', 'incident');
dict.addQuery('element', 'STARTSWITH', 'u_'); // Custom fields
dict.query();
 
while (dict.next()) {
    gs.info(dict.element + ' — Type: ' + dict.internal_type);
}

CMDB — Configuration Item Database

The CMDB is ServiceNow's inventory of everything the IT organisation is responsible for. Every server, application, network device, database, and service is a Configuration Item (CI).

CMDB Table Hierarchy

cmdb_ci (parent — all CIs)
├── cmdb_ci_server         ← Physical and virtual servers
│     ├── cmdb_ci_linux_server
│     └── cmdb_ci_win_server
├── cmdb_ci_appl           ← Software applications
├── cmdb_ci_database       ← Database instances
├── cmdb_ci_network_adapter← Network devices
├── cmdb_ci_service        ← Business/IT services
└── cmdb_ci_endpoint       ← Workstations, laptops

Key CMDB Fields

Relationships

CIs are linked via the cmdb_rel_ci table:

cmdb_rel_ci
├── parent    → CI A
├── child     → CI B
└── type      → "Runs on::Runs" / "Hosted on::Hosts" / "Depends on::Used by"

Example: Linking an incident to a CMDB CI:

// Business Rule: link incident to CI based on category
(function executeRule(current, previous) {
    if (current.category == 'network') {
        var ci = new GlideRecord('cmdb_ci_network_adapter');
        ci.addQuery('name', current.short_description);
        ci.setLimit(1);
        ci.query();
        if (ci.next()) {
            current.cmdb_ci = ci.sys_id;
        }
    }
})(current, previous);

Platform Data Model — Summary

Common Data Model Mistakes

Part of the Digital Kimya (opens in a new tab) ServiceNow Guide Series — Identity & Access · Scripts & Logic · Deployment