Data Schema & Import Sets | ServiceNow CSA Part 4

Section 1

Table Architecture

ServiceNow stores all data in database tables. Understanding how tables are defined, registered, and related to each other is fundamental to everything else in the platform.

sys_db_object — The Table Registry

Every table in ServiceNow is itself a record in the sys_db_object table. This is ServiceNow's internal table registry — it defines all tables that exist on the platform.

sys_db_object

The table registry. Every user-defined and platform table has a record here. Contains the table name, label, parent (extended) table, and configuration metadata.

Navigate: type sys_db_object.list in the filter navigator

sys_dictionary

The column (field) registry. Every field on every table has a record here. Defines field type, max length, default value, and dictionary overrides.

Navigate: type sys_dictionary.list in the filter navigator

sys_choice

Stores all choice list values for Choice fields. Choice fields display a dropdown — each option is a row in sys_choice with a label and value.

Navigate: type sys_choice.list in the filter navigator

The sys_id — Universal Record Identifier

Every record in every ServiceNow table has a sys_id — a globally unique identifier (GUID) that never changes for the lifetime of that record.

Exam Must-Know — sys_id Format: A sys_id is a 32-character hexadecimal string (128-bit UUID). Example: 9d385017c611228701d22104cc95c371. It contains only characters 0–9 and a–f. ServiceNow uses sys_ids for all record references, foreign keys, and relationships — never plain integers.

System Fields on Every Table

All ServiceNow tables automatically inherit a set of system audit fields. These fields are present on every record, on every table, without exception.

Field	Type	Description
`sys_id`	GUID (32 hex chars)	Unique identifier for the record. Never changes. Used as primary key and foreign key reference.
`sys_created_on`	Date/Time	Timestamp when the record was first created. Set automatically; cannot be modified.
`sys_created_by`	String	Username of the user who created the record. Set automatically at creation.
`sys_updated_on`	Date/Time	Timestamp of the most recent modification to the record. Updated on every save.
`sys_updated_by`	String	Username of the user who last modified the record. Updated on every save.
`sys_class_name`	String	The actual table name of the record within an extended hierarchy. Critical for polymorphic queries.

Why sys_class_name Matters: When a table extends another (e.g., incident extends task), querying the parent task table returns rows from all child tables mixed together. The sys_class_name field tells you which actual table each row belongs to — incident, change_request, problem, etc. Without it, you cannot distinguish record types in a polymorphic query.

Table Inheritance (Extends)

ServiceNow supports single-table inheritance. A child table can extend a parent table, inheriting all of the parent's columns while adding its own unique fields.

Child table rows are stored in the same physical database rows as parent table data
All parent columns are accessible on child records
The child table can add new fields that only exist on that table
Querying the parent table returns records from all child tables (polymorphic)
Querying a child table returns only records of that specific type

The task Table — Root of the ITIL Hierarchy

The task table is the most important extended table in ServiceNow. It is the root parent for all core ITIL process tables.

task                          ← Root parent table
├── incident                  ← Extends task
├── problem                   ← Extends task
├── change_request            ← Extends task
│   ├── change_task           ← Extends change_request
├── sc_task                   ← Extends task (service catalog task)
├── sc_req_item               ← Extends task (catalog item request)
└── sn_si_incident            ← Extends task (security incident)

Because all these tables extend task, they all share common fields like number, short_description, state, assigned_to, assignment_group, priority, and opened_at.

Flat vs. Extended Tables:

Extended table — inherits columns from a parent table. Example: incident extends task. Records appear in both the child table and the parent table query.
Flat table — does not extend any other table (or only extends the base sys_metadata). Example: sys_user (users table) is essentially flat — it does not extend a domain-specific parent.

Exam Trap — Querying Extended Tables: If you query task.list, you will see records from incident, change_request, problem, and all other task child tables mixed together. Use sys_class_name=incident to filter to a specific child type, or query the child table directly via incident.list.

Section 2

Import Sets — Overview

Import Sets are ServiceNow's mechanism for loading external data into the platform. They use a two-stage process: first load data into a staging table, then transform it into the target production table.

The Two-Stage Process:

Load — Raw data is loaded into a temporary import set (staging) table
Transform — A transform map moves and converts data from staging to the target table

This separation means you can inspect and clean data in the staging area before it reaches production tables.

Key Tables in the Import Set System

Table Name	Purpose	Note
`sys_import_set`	Tracks each import set run — the "container" for a batch of imported rows	One record per import operation
`u_imp_*`	The actual staging table where raw imported rows land	Auto-created with `u_` prefix and auto-generated suffix
`sys_import_set_row`	Tracks the result of each individual row: inserted, updated, error, or skipped	One record per row per import run
`sys_transform_map`	Defines the transform — source table, target table, and settings	Must be created before running transform
`sys_transform_entry`	Individual field mapping rules within a transform map (source field → target field)	One record per mapped field
`sys_data_source`	Defines the external data source — file type, connection details, credentials	Referenced by scheduled imports

Import Set Staging Table Naming

When you upload a file (Excel or CSV) to create an import set, ServiceNow automatically creates a staging table with a u_imp_ prefix. The table name is derived from the file name or can be specified manually.

Exam Fact: Import set staging tables are always prefixed with u_ (the user-created table prefix) and typically contain imp in the name. Example: u_imp_users_from_hr. They are temporary staging areas — data in them is not meaningful until transformed to a target table.

Data Loading Methods

File Upload (Excel / CSV)

Most common method. Upload a .xlsx or .csv file directly via the ServiceNow UI. ServiceNow reads column headers and creates matching staging table columns automatically.

JDBC

Connect to an external relational database (Oracle, SQL Server, MySQL) via JDBC. Run a SQL query to pull records directly into an import set staging table.

REST Web Service

POST data to the ServiceNow Import Set REST API endpoint. Allows external systems to push data in real-time into a staging table without file uploads.

SFTP / FTP

Pull a file from a remote SFTP/FTP server on a schedule. ServiceNow retrieves the file automatically and loads it into the staging table — no manual upload required.

LDAP

Import user directory data from an LDAP/Active Directory server. Commonly used for user provisioning and synchronization.

HTTP

Retrieve data from a URL (REST/HTTP endpoint) as part of a scheduled import. ServiceNow fetches and parses the response into the staging table.

Import Set Run Process — Load → Transform → Result

Every import set operation follows the same three-stage lifecycle:

┌─────────────────────────────────────────────────────────────┐
│  STAGE 1: LOAD                                              │
│  External data (CSV/XLSX/JDBC/REST) → Import Set Table      │
│  Raw rows land in u_imp_* staging table                     │
│  No transformation yet — data in raw source format          │
├─────────────────────────────────────────────────────────────┤
│  STAGE 2: TRANSFORM                                         │
│  Transform Map applies field mappings + coalesce rules      │
│  Scripts (onBefore/onAfter) execute for complex logic       │
│  Each row: MATCH existing? → UPDATE : INSERT                │
├─────────────────────────────────────────────────────────────┤
│  STAGE 3: RESULT                                            │
│  sys_import_set_row records show per-row outcome:           │
│  inserted / updated / error / skipped / ignored             │
│  Target table now contains the transformed records          │
└─────────────────────────────────────────────────────────────┘

Reviewing Import Results: After a transform, navigate to the import set record in sys_import_set.list and open the import set rows to see the per-row result status. Error rows will show why they failed. This is the primary debugging tool for import issues.

Section 3

Transform Maps — In Depth

A Transform Map is the rulebook that tells ServiceNow how to move data from the import set staging table into the target production table. Without a transform map, you cannot run a transform.

Transform Map Components

Source Table

The import set staging table (u_imp_*) that contains the raw loaded data. This is the "from" side of the mapping.

Target Table

The production ServiceNow table where records should land. Examples: sys_user, cmdb_ci_server, incident. This is the "to" side.

Field Mappings

Individual rules connecting a source field (staging column) to a target field (production column). Created as sys_transform_entry records.

Coalesce Fields

Designated "match key" fields. If a record in the target table matches on a coalesce field, the existing record is updated. If no match, a new record is inserted.

Transform Scripts

Server-side JavaScript attached to individual field mappings. Runs per-row to perform complex value transformations (e.g., concatenate fields, look up reference values).

Map Scripts (onBefore / onAfter)

Scripts that run at the transform map level — onBefore runs before any fields are mapped for a row, onAfter runs after all fields are mapped and the record is about to be saved.

Field Mapping Details

Each field mapping in a transform map specifies:

Property	Description	Example
Source field	Column name in the import set staging table	`u_first_name`
Target field	Column name in the production target table	`first_name`
Coalesce	If checked, this field is used as a match key to find existing records	Checked on `email` field
Use source script	If enabled, a script transforms the source value before mapping it	Transform date format
Choice action	What to do when a choice field value doesn't match existing choices: ignore, reject, create	`create`

Coalesce — How Deduplication Works

Coalesce is the mechanism that prevents duplicate records when importing data that may already exist in the target table.

Exam Critical — Coalesce Logic:

For each row being transformed, ServiceNow checks the target table for a record where the coalesce field value matches
If a match is found → the existing record is UPDATED with the new data
If no match is found → a new record is INSERTED

The coalesce field must contain a unique value in the target table (e.g., email address, employee ID) for this to work correctly.

// Coalesce decision logic (conceptual pseudocode)
for each row in import_set_staging_table:
    existing = target_table.findWhere(coalesce_field == row.coalesce_value)

    if existing:
        existing.update(mapped_field_values)   // UPDATE
        row.result = "updated"
    else:
        target_table.insert(mapped_field_values)  // INSERT
        row.result = "inserted"

Multiple Coalesce Fields: You can mark multiple fields as coalesce. When multiple coalesce fields exist, ServiceNow ANDs them together — a match requires ALL coalesce fields to match. This is useful for composite keys (e.g., match on both first name AND employee ID).

Transform Map Scripts

Transform scripts allow server-side JavaScript to run during the transform process, giving you full control over complex transformation logic.

Script Type	When It Runs	Access To	Common Use
Field mapping script	When that specific field is being mapped for each row	`source` (staging row), `answer` (return value)	Transform a date format, concatenate fields, look up a reference
onBefore script	Before any field mappings run for a row	`source` (staging row), `target` (GlideRecord being built)	Pre-processing, setting ignore flag, skipping rows conditionally
onAfter script	After all field mappings run, before saving the target record	`source`, `target`, `action` (insert/update)	Post-processing, sending notifications, logging, related record updates

// Example: onBefore script — skip rows marked as inactive
if (source.u_status == 'inactive') {
    ignore = true;  // skip this row entirely
}

// Example: Field mapping script — transform full name to first/last
// (set on the target "first_name" field mapping)
var parts = source.u_full_name.split(' ');
answer = parts[0];  // return value becomes the field value

// Example: onAfter script — log the action
gs.log('Import row ' + action + ': ' + target.getDisplayValue(), 'ImportTransform');

Auto Map Matching Fields

The Auto Map Matching Fields button on a transform map automatically creates field mapping entries for any staging table column whose name exactly matches a field name in the target table. This saves manual effort when column names are already aligned.

Workflow Tip: When creating a transform map, click Auto Map Matching Fields first to generate mappings for all directly-matching columns, then manually add or adjust mappings for fields that have different names or require transformation scripts.

Section 4

Data Sources (sys_data_source)

A Data Source defines the connection to an external data provider. Rather than re-specifying connection details each time, you create a reusable data source record and reference it from scheduled imports.

Data Source Types

File (Excel / CSV)

Pull data from a file attachment, a URL, or an SFTP server. The most common data source type for one-time and scheduled file-based imports.

Formats: .xlsx, .csv, .xml

JDBC

Direct database connection to an external RDBMS. Specify JDBC URL, driver class, credentials, and a SQL query. ServiceNow executes the query and loads results.

Databases: Oracle, SQL Server, MySQL, PostgreSQL

LDAP

Connect to an LDAP or Active Directory server to pull user and group data. Define the base DN, filter, and attributes to retrieve.

Primary use: User provisioning and sync

REST

Call an external REST API and load the JSON or XML response. Specify the URL, HTTP method, headers, authentication, and response format.

Supports Basic Auth, OAuth 2.0

Data Source Key Fields

Field	Description
Name	Descriptive name for the data source
Import set table name	The staging table that data is loaded into (can be auto-generated or manually specified)
Type	File, JDBC, LDAP, REST — determines which connection fields appear
Connection info	URL, host, credentials, query — specific to the type selected
Run as	The ServiceNow user context under which the import runs (affects permissions)

Scheduled Imports

A Scheduled Import links a Data Source to a Transform Map and runs on a configurable schedule. This automates the full import pipeline without manual intervention.

Navigate to: System Import Sets > Scheduled Imports
Set the data source, transform map, and schedule (daily, weekly, cron expression)
ServiceNow will automatically load and transform data at the specified time
The Test connection button verifies that the data source can be reached
Import logs and results are available in sys_import_set.list after each run

Connection Testing: Before scheduling a data source, always use the Test connection or Load data buttons to verify the connection works and inspect the data before creating the transform map. This helps identify column names and data formats upfront.

Section 5

Step-by-Step: Excel / CSV Import Workflow

The file upload import is the most common import path tested on the CSA exam. Know every step in this workflow.

Step 1 — Upload the File

Navigate to System Import Sets > Load Data. Select or create an import set table name (or let ServiceNow auto-generate one with the u_ prefix). Upload your .xlsx or .csv file and click Submit.

Result: An import set staging table is created and populated with the raw rows from your file. Column headers become table fields.

Step 2 — Inspect the Staging Data

Review the newly created import set table to verify all rows loaded correctly. Check that column names, data types, and values look as expected. Identify which field will serve as your coalesce (match) key.

Step 3 — Create a Transform Map

Navigate to System Import Sets > Transform Maps > New. Set the Source table (your staging table) and Target table (the production table). Give it a descriptive name and save.

Step 4 — Map Fields

Open the transform map. Click Auto Map Matching Fields to auto-create mappings for columns with identical names. Then manually add or edit mappings for remaining fields. Mark the appropriate field as Coalesce.

Step 5 — Run the Transform

From the import set record, click Transform. Select your transform map and click Transform again to execute. ServiceNow processes each staging row and inserts/updates records in the target table.

Step 6 — Review Import Set Rows

After the transform completes, open the import set and examine the Import Set Rows related list. Each row shows its result: inserted, updated, error, skipped, or ignored. Investigate error rows by reading the error message in the row record.

Exam Fact — Row Result States: The sys_import_set_row table tracks the per-row transform outcome. Know these states:

inserted — No coalesce match found; new record created in target table
updated — Coalesce match found; existing record updated
error — Transform failed for this row; check error message
skipped — Row was skipped (e.g., due to an onBefore script setting ignore = true)
ignored — Row was excluded before transform began

Section 6

Update Sets vs. Import Sets — Critical Distinction

This is one of the most commonly tested distinctions on the CSA exam. Update Sets and Import Sets sound related and are often confused — they serve completely different purposes.

Aspect	Update Sets	Import Sets
Primary purpose	Migrate configuration (metadata) between ServiceNow instances	Import data (records) from external sources into a table
What moves?	Platform configuration: UI policies, business rules, forms, workflows, scripts	Business data: user records, CI records, incident data, asset lists
Source	Another ServiceNow instance (dev → test → production pipeline)	External system: CSV file, JDBC database, REST API, SFTP
Direction	ServiceNow instance → (exported) → another ServiceNow instance	External file/system → ServiceNow instance
Key table	`sys_update_set`	`sys_import_set`
Transform map needed?	No — configuration is applied directly during merge/preview/commit	Yes — a transform map is required to map staging fields to target fields
Example use case	Deploy a new business rule from development to production	Import 10,000 employee records from an HR system CSV file

Exam Trap — Never Confuse These: If a question asks "how do you move a business rule from dev to prod?" — the answer is Update Sets. If a question asks "how do you load user data from an external HR CSV file?" — the answer is Import Sets. They are completely separate mechanisms with no overlap in function.

Memory Aid:

Update Sets = "Update the system configuration" = config migration between instances
Import Sets = "Import data from outside" = bring external data into the platform

Section 7

Key Exam Facts & Rapid-Fire Review

This section consolidates the highest-frequency exam facts for Data Schema and Import Sets. Review these before your exam.

Coalesce Facts

Coalesce = the "match key" — the field(s) used to look up an existing record in the target table.

Coalesce field value must be unique in the target table to work reliably
Coalesce match found → UPDATE existing record
No coalesce match → INSERT new record
Multiple coalesce fields = AND logic (all must match)
Without coalesce, every row inserts a new record (no deduplication)

Import Set System Facts

Import Set Staging Tables:

Always prefixed with u_ (user-created table prefix)
Auto-created when you upload a file or load data
sys_import_set_row tracks per-row result: inserted / updated / error / skipped / ignored
A transform map must exist before you can run a transform — transforms do not run without one
Multiple transform maps can exist for the same source/target table pair

Table Architecture Facts

sys_class_name:

sys_class_name is critical for identifying a record's actual table in an extended hierarchy
All task child records queried via task.list will show their sys_class_name as incident, change_request, etc.
Polymorphic task hierarchy queries must use sys_class_name to filter by specific record type
sys_id = 32 hexadecimal characters = GUID = never changes for record's lifetime
sys_db_object = table registry (every table is a record here)

Transform Map Facts

Transform Map Checklist:

sys_transform_map = the transform map itself (one per import pipeline)
sys_transform_entry = individual field mapping records within a transform map
Auto Map Matching Fields = button that auto-creates mappings for identically-named fields
onBefore script = runs before field mappings; can set ignore = true to skip the row
onAfter script = runs after all field mappings; action variable is "insert" or "update"
Field mapping scripts use answer variable to return the transformed value

Quick-Reference: Import Set vs Update Set

Question	Answer
Move a business rule from dev to prod?	Update Set
Load CSV data from an HR system?	Import Set
Table used for staging imported data?	*`u_imp_`** (auto-created with u_ prefix)
What prevents duplicate records during import?	Coalesce field
Coalesce match found → what happens?	UPDATE the existing record
No coalesce match → what happens?	INSERT a new record
Table that registers all tables?	`sys_db_object`
Field that identifies record type in extended hierarchy?	`sys_class_name`
Format of sys_id?	32 hexadecimal characters (GUID)
Root parent of ITIL process tables?	`task` table
Table tracking per-row import results?	`sys_import_set_row`
Script type that can skip a row during transform?	onBefore script (set `ignore = true`)

Part 4 — Big Picture: This topic (data schema and imports) underpins everything else in Part 4. A solid understanding of how tables are structured, how inheritance works, and how import sets flow from staging to target is foundational for the CMDB, ACL, and scripting topics that follow. Return here to reinforce these concepts after completing the rest of Part 4.