5.3 Data Management & Administration
Key Takeaways
- Importing data uses an Import Set staging table plus a Transform Map that maps source columns to target table fields, optionally coalescing to update existing records.
- Business Rules run server-side on database operations; Client Scripts run in the browser on form events — the server vs. client distinction is heavily tested.
- Field-level security is enforced by field-level ACLs, while Data Policies enforce mandatory and read-only rules across the UI, imports, and integrations.
- UI Policies enforce form behavior client-side only; Data Policies enforce data rules everywhere data enters the table.
- Field auditing (the Audit dictionary attribute) records field changes to sys_audit, and System Logs capture platform activity for troubleshooting.
Why Data Administration Is Tested Heavily
The CSA exam expects administrators to move data into the platform correctly and to enforce rules without breaking integrations. The recurring theme of this section is where logic executes: server vs. client, and UI vs. all data-entry paths. Choosing the wrong tool (for example, a Client Script when you needed a Business Rule) is a classic mistake the exam probes.
Import Sets and Transform Maps (the Relationship)
ServiceNow does not load external data directly into production tables. Instead it uses a two-stage import pattern:
- Import Set table — a temporary staging table (prefixed
sys_import_set_row/ a generatedimp_table) that receives the raw source data exactly as supplied (CSV, Excel, JDBC, REST, etc.). Nothing is validated here yet. - Transform Map — defines how each source column maps to a target table field. When the transform runs, rows move from the staging table into the real target table (for example,
sys_userorcmdb_ci_computer).
Key concepts the exam tests:
| Concept | What it does |
|---|---|
| Field map | Maps one source column to one target field |
| Coalesce | Marks a field as the match key: if a record with the same value exists, the import updates it instead of inserting a duplicate |
| onBefore / onAfter transform script | Custom logic during the transform |
| Transform | The action that moves staged rows into the target table |
Without a coalesce field, every import row creates a new record. With coalesce, matching rows are updated — this is how you keep imports idempotent.
Business Rules vs. Client Scripts (Server vs. Client)
This is one of the most frequently tested distinctions on the entire exam.
| Aspect | Business Rule | Client Script |
|---|---|---|
| Where it runs | Server (database tier) | Client (user's browser) |
| Triggered by | Database operations: insert, update, delete, query | Form events: onLoad, onChange, onSubmit, onCellEdit |
| Timing options | before, after, async, display | n/a |
| Runs on import/integration data? | Yes — enforced on all insert/update paths | No — only when a user uses a form |
| Typical use | Data validation, defaulting, integrity, automation | UI feedback, show/hide, instant field changes |
The critical takeaway: Client Scripts do not run during imports, web services, or background scripts because there is no browser form. If a rule must be enforced no matter how the data arrives, it must be a Business Rule (server-side). Use Client Scripts only for interactive form behavior.
UI Policies vs. Data Policies
Closely related to the server/client question:
- UI Policy — runs client-side on the form to dynamically set fields mandatory, read-only, or visible based on conditions. It does not enforce anything for imports or integrations because it only acts on the form.
- Data Policy — enforces mandatory and read-only rules at the data layer, so the rule applies to form submissions and imports, web services, and other programmatic inserts/updates. A Data Policy can optionally be converted to also run as a UI Policy.
Rule of thumb for the exam: if a constraint must hold regardless of how data enters the table, use a Data Policy (or a Business Rule). If it is purely interactive form behavior, a UI Policy is appropriate.
Field-Level Security
Field-level security is enforced through field-level ACLs (covered in section 5.2): a table.field ACL for the read or write operation controls whether a user can see or edit that specific column. This is the authoritative security control. UI Policies and Data Policies can make a field read-only, but they are not security boundaries — a determined user or integration could bypass UI behavior; only an ACL is enforced server-side as access control.
Auditing
ServiceNow can record a history of changes to individual fields. When a field's dictionary Audit attribute is enabled (or the table is audited), every change is written to the sys_audit table, which powers the Activity / History stream and the History > List / Calendar views on a record. Auditing answers "who changed what, when, and from what value to what value" — essential for compliance and troubleshooting. Auditing adds storage and minor write overhead, so enable it deliberately on tables that need accountability.
System Logs
The System Logs application captures platform activity used for troubleshooting:
| Log | Purpose |
|---|---|
System Log > All (syslog) | Errors, warnings, and information messages from scripts and the platform |
| Transaction logs | Per-transaction performance and response times |
| Email logs | Inbound/outbound email processing |
| Import logs | Import set and transform results |
Log entries written by scripts use gs.info(), gs.warn(), and gs.error(). When data looks wrong after an import, the import logs plus the system log are the first places an administrator should check, followed by any Business Rules or Transform scripts that ran on insert.
An administrator needs a validation that rejects bad data whether it arrives through a form, a nightly CSV import, or an inbound REST integration. Which tool should they use?
During a CSV import, an administrator wants existing user records to be UPDATED rather than duplicated when the email address already exists. What must be configured on the Transform Map?
Which statement correctly distinguishes a UI Policy from a Data Policy?