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. A UI policy applies to child (extended) tables only when its Inherit option is selected.
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, groups, and group memberships are also not captured by default and must be moved another way. Role definitions and ACL rules are configuration and are captured.
- 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; a limited client-side GlideRecord API also exists in global scope) 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. Client Script
- D. Field ACL
Why: A UI Policy runs in the browser and can make a field mandatory, read-only, or visible based on a condition, with no scripting required. A client script could also change the field in the browser, but it requires JavaScript. A business rule runs on the server when the record is saved, so the form does not change instantly. A field ACL controls whether a user can read or write the field; it cannot make the field mandatory.
A developer wants a server-side rule that rejects an update with current.setAbortAction(true) when a required value is missing, so the invalid change is never written to the database. Which Business Rule timing should they choose?
- A. after
- B. display
- C. before ✓
- D. async
Why: A 'before' business rule runs on the server before the database write, so it can check the values on the current record and call current.setAbortAction(true) to stop the update. An 'after' rule runs once the record has already been written, so it is too late to stop the save. An 'async' rule runs later as a background job, and a 'display' rule runs when the form loads, not when the record is saved.
Which TWO statements about update sets are correct? (Choose two.)
- 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 new incident and user records along with the configuration changes
- D. Changes are applied to the target as soon as the update set is marked Complete on the source
Why: Update sets capture configuration, such as business rules and form layouts, and are promoted by retrieving the update set on the target, previewing it to resolve collisions, and then committing it. They do not capture data records such as incidents or users; those are moved with import sets or XML export. Marking an update set Complete on the source only closes it for changes: nothing reaches the target until it is retrieved, previewed, and committed there.