Tables, Dictionary, References, and Imports
Key Takeaways
- A ServiceNow table defines the record container for an application; extending a parent table inherits fields and behavior, while standalone tables start with a cleaner custom model.
- Dictionary entries define field metadata such as type, label, length, default value, mandatory behavior, display value, reference target, and choice behavior.
- Reference fields store record links and enable related lists and dot-walking, while ordinary string fields cannot safely replace relationships.
- Dot-walking traverses reference fields in lists, filters, conditions, scripts, templates, and notifications, but excessive chains can hurt performance and clarity.
- Imports stage raw rows in import set tables, then transform maps write to target tables; coalesce decides whether a matched target record is updated instead of duplicated.
Start With the Record Model
A ServiceNow application is only as good as its data model. A table stores records of one type, and ServiceNow automatically gives that table platform behavior such as forms, lists, system fields, 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, activity, comments, and work notes may belong under Task. A pure reference table, such as Regions or Approved Vendors, is often better as a standalone table. Extension is powerful, but it commits the child table to inherited fields and behaviors, so choose it for real shared semantics rather than convenience.
Dictionary Entries Are the Field Contract
The dictionary is the metadata layer for tables and fields. A dictionary entry controls what a field is and how it behaves across the platform. Form layout changes what users see on a page; dictionary configuration defines the field itself.
| Dictionary concern | Why CAD candidates should care |
|---|---|
| Field type | Determines storage and behavior, such as String, Choice, Date/Time, Reference, or True/False |
| Default value | Provides an initial value for new records when the field type supports it |
| Mandatory/read-only settings | Field-level behavior that may also be enforced with policies or rules |
| Display value | Controls the human-readable label shown when other records reference this table |
| Reference specification | Points the field at a target table and can use qualifiers to limit choices |
| Dictionary override | Lets an extended child table adjust inherited field behavior without redefining the parent field |
A status field with a known set of values is usually a Choice, not a free-text string. A relationship to a user, group, vendor, department, or parent record should usually be a Reference, not a copied name.
References, Related Lists, and Dot-Walking
A reference field stores a link to one record on another table. Users usually see the referenced record's display value, but the relationship is stored as an internal record link. That design supports related lists: when many child records point to one parent, the parent form can show those children automatically.
Reference fields also enable dot-walking. From a record that has requested_for, a developer can reach fields on the referenced user, such as requested_for.department or requested_for.manager.email. Dot-walking appears in list column selection, filters, condition builders, scripts, notification variables, and reporting. Use it to avoid duplicating data, but keep chains understandable. A long chain can make filters harder to debug and scripts slower.
Import Sets, Transform Maps, and Coalesce
External data should not be written straight into the target application table. ServiceNow stages incoming rows in an import set table first. A transform map then maps source columns to target fields, runs optional transform logic, and inserts or updates the target records.
Coalesce is the high-yield import concept. A coalesce field is the match key used during transform. If the target table already has a record with the same coalesce value, ServiceNow updates that record. If no match exists, it inserts a new record. With no coalesce, recurring loads commonly create duplicates. Use a stable unique field, such as employee number, vendor ID, or external system ID, and avoid coalescing on values that are blank, reused, or likely to change.
Imports also test the boundary between data rules and UI rules. A UI Policy will not protect a nightly import, because there is no user form. If a field must be mandatory or read-only for imports and integrations as well as forms, use a Data Policy, Business Rule, or ACL depending on whether the problem is data quality, logic, or authorization.
A CAD team imports a nightly supplier spreadsheet into a scoped Supplier table. Each supplier has a stable external_supplier_id, and repeat imports are creating duplicates. What is the best fix?
Match each CAD data concept to its primary job.
Match each item on the left with the correct item on the right