Data Migration and Integration
About 13% of the CSA exam — see all 6 domains.
What this domain covers
- UI Policies
- Business Rules
- System update sets
- Scripting in ServiceNow
What it covers: UI Policies, Business Rules, update sets, and scripting basics. (Despite the name, this domain is largely about client/server logic and moving configuration between instances.)
UI Policies dynamically change a form in the browser — making fields mandatory, read-only, or visible based on conditions — without writing scripts (though scripts are optional). They run client-side.
Business Rules are server-side scripts that run when records are queried, inserted, updated, or deleted. Timing options:
- before — modify the record before it's written to the database.
- after — run logic after the write (e.g., update related records).
- async — run in the background via a scheduled job.
- display — run before the form loads to set up
g_scratchpaddata for client scripts.
Know the difference: UI Policy = client-side form behavior, no/low code; Business Rule = server-side database logic. Client Scripts also run client-side but require scripting.
Update sets capture configuration changes (form layouts, business rules, UI policies, etc.) so they can be moved from a sub-production instance to production. Key points:
- Data records (like incidents) are not captured by update sets — only configuration. Notably, users, roles, groups, and ACL data records are also not captured by default and must be moved another way.
- A Default update set exists; you create a named one and make it current before making changes you want captured.
- Promotion flow: complete the update set → export/retrieve to the target instance → preview (resolve collisions) → commit.
Scripting: ServiceNow uses JavaScript. The two main server-side APIs are GlideRecord (query/insert/update/delete records) and GlideSystem (gs) (utility functions like gs.info(), gs.getUser()). Client-side scripting uses the g_form and g_user APIs.
Sample questions from this domain
Three of the 39 in this domain, with the reasoning. The full set is in the question bank.
An administrator needs a field to become mandatory on a form only when another field has a specific value, and wants this to happen instantly in the browser without server interaction or scripting. Which tool is the best fit?
- A. Business Rule
- B. UI Policy ✓
- C. Transform Map
- D. Scheduled Job
Why: UI Policies run client-side and can make fields mandatory, read-only, or visible based on conditions, with no scripting required. Business rules run server-side, scheduled jobs run in the background, and transform maps handle imports.
A developer wants logic to run on the server to modify a record's values BEFORE it is written to the database during an update. Which Business Rule timing should they choose?
- A. after
- B. display
- C. before ✓
- D. async
Why: A 'before' business rule executes server-side before the database write, so it can alter field values on the current record. 'after' runs post-write (often to update related records), 'async' runs later as a job, and 'display' prepares data for the form before it loads.
Which TWO statements about update sets are correct?
- A. Changes are moved to another instance by retrieving, previewing, and committing the update set ✓
- B. Update sets capture configuration changes such as new business rules and form layouts ✓
- C. Update sets capture data records such as incidents and users
- D. Update sets permanently delete the source configuration after export
Why: Update sets capture configuration (not data records like incidents), and they are promoted to another instance via retrieve → preview (resolve collisions) → commit. They do not delete the source configuration, and data records are migrated by other means (e.g., import sets).