Tables, Dictionary, References, and Imports

Start With the Record Model

A ServiceNow application is only as good as its data model. A table stores records of one type, and the platform automatically gives that table forms, lists, system fields (sys_id, sys_created_on, sys_updated_by), and metadata records. For CAD, the first decision is whether to extend an existing table or create a standalone custom table.

Extend a parent table when the app truly needs inherited behavior. A work item that needs assignment, state, priority, the activity stream, comments, and work notes usually belongs under Task (task), because extending Task inherits those fields and the workflow plumbing for free. A pure reference table such as Regions or Approved Vendors is usually better standalone, because it needs none of Task's lifecycle baggage. Extension is powerful, but it commits the child to the parent's fields and behaviors and to the parent's ACLs, so choose it for genuine shared semantics, not convenience.

Naming matters on the exam: a new scoped table gets a prefixed internal name like x_acme_vendor_review, and reusing the same column on a child table is handled with a dictionary override, not a new field.

Dictionary Entries Are the Field Contract

The dictionary is the metadata layer for tables and fields. A dictionary entry (sys_dictionary) controls what a field is and how it behaves platform-wide. Form layout changes what users see; dictionary configuration defines the field itself.

A status field with a fixed set of values is a Choice, not free text. A relationship to a user, group, vendor, or parent record is a Reference, not a copied name string.

References, Related Lists, and Dot-Walking

A reference field stores a link (the target record's sys_id) to one record on another table. Users see the referenced record's display value, but the stored value is the internal link. That design powers related lists: when many child records point to one parent, the parent form automatically shows those children.

Reference fields also enable dot-walking — traversing the reference to reach fields on the related record. From a record with requested_for, a developer can read requested_for.department or chain further to requested_for.manager.email. Dot-walking appears in list column selection, filters, the condition builder, scripts (current.requested_for.email), notification variables, and reports. Use it to avoid duplicating data, but keep chains short: a four-hop chain is hard to debug and forces extra database lookups, which slows scripts and list rendering.

Know the related relationship types for the exam:

• Reference — one record points to one parent record (many-to-one).
• List (Glide List) — one field holds many sys_ids (many-to-many lite).
• Many-to-Many table — an explicit junction table joining two tables.
• Database View — a read-only join across tables for reporting.

A worked example: a Vendor Review record references one Vendor (vendor reference field), and each Vendor references one Account Manager (a user). On the review list a developer can add the column vendor.account_manager.email by dot-walking two hops, with no scripting and no duplicated email field. If that email were instead copied into a plain string on the review, it would go stale the moment the manager changed — the relationship is the single source of truth.

Import Sets, Transform Maps, and Coalesce

External data should never be written straight into the target application table. ServiceNow stages incoming rows in an import set table (u_import...) first. A transform map then maps source columns to target fields, runs optional transform scripts (onBefore, onAfter), and inserts or updates target records.

Coalesce is the highest-yield import concept on the exam. A coalesce field on a field map is the match key. During transform, if a target record already has the same coalesce value, ServiceNow updates it; if no match exists, it inserts a new record. With no coalesce, every recurring load creates duplicates. Choose a stable unique key such as employee number, vendor ID, or external system ID, and avoid coalescing on blank, reused, or changing values. You may coalesce on multiple fields together to form a composite key.

Imports also test the boundary between data rules and UI rules. A UI Policy never runs for a nightly import because there is no user form. If a field must be mandatory or read-only for imports, integrations, and forms, use a Data Policy (which can be converted to/from a UI Policy), a Business Rule, or an ACL — depending on whether the issue is data quality, server logic, or authorization.