Overview
Data Migration and Integration groups four objectives about logic and movement. UI policies change form fields on the client, making them mandatory, visible or read-only when conditions are met, without code. Business rules run on the server when records are queried, inserted, updated or deleted, and their timing (before, after, async or display) decides what they can safely do. System update sets capture configuration changes in one instance so they can be moved, previewed and committed in another.
Scripting in ServiceNow ties these together: client scripts and the g_form API on forms, server scripts with GlideRecord and GlideSystem, Script Includes for reusable server code, and UI actions for buttons and links. The CSA expects you to read simple scripts and know where each type runs, not to write large programs. The domain builds on the tables and access rules of Domain 5 and the instance model of Domain 1.
How it's tested
Questions present a requirement and ask which logic type, timing or tool meets it, or show a short script and ask what it does or where it runs. Update set questions follow the migration sequence and its preview step. Expect comparisons between no-code and scripted options, where the exam prefers UI policies over client scripts when either would work.
-
Pick the logic type
A behaviour is described and you choose UI policy, data policy, client script, business rule or Script Include based on where and when it must run.
-
Business rule timing
A server-side need is described and you choose before, after, async or display based on whether the record, related records or the form is affected.
-
Migration sequence
An update set scenario asks for the next step or how to handle a preview problem or collision before committing.
A requirement says the Assignment group must be required when State is In Progress, including for records created through an integration. Options are a UI policy, a client script, a data policy and a before business rule that aborts. UI policies and client scripts act only on forms, so integration records bypass them. A data policy enforces mandatory fields for all data sources without code, making it the best answer.
Objectives 4
Official objectives from the ServiceNow outline, in outline order.
6.1 UI PoliciesNo-code, client-side control of form fields.
- What it means
- A UI policy applies UI policy actions to fields on a form when its conditions are met, setting them mandatory, visible or read-only. Options include whether it applies on load, whether it reverses when the condition becomes false, whether it applies to all views and to tables that extend this one.
- What to understand
- UI policies run in the browser, after client scripts on form load, and affect only forms, so they do not stop changes made through lists, imports or integrations. A data policy enforces mandatory and read-only rules on the server for all data sources and can also be applied as a UI policy. Prefer a UI policy over a client script when the goal is only mandatory, visible or read-only behaviour.
- How it shows up
- A field must become mandatory when another field has a certain value, and you choose a UI policy with Reverse if false selected.
- Common confusion
- Treating a UI policy as server-side enforcement, or writing a client script for something a UI policy can do without code.
6.2 Business RulesServer-side logic triggered by database operations.
- What it means
- A business rule runs on the server when a record is displayed, queried, inserted, updated or deleted, filtered by conditions. Simple rules can set field values, show a message or abort the action without code, and advanced rules run a script with access to current and previous.
- What to understand
- Before rules run before the database write and can change current without calling update(); after rules run after the write and suit changes to other records; async rules run after the write as a background job and suit slower work such as integrations; display rules run before a form loads and can pass data to client scripts through g_scratchpad. Calling current.update() in a before or after rule causes extra saves and can trigger recursion.
- How it shows up
- A field on the same record must be set automatically when it is saved, and you choose a before business rule.
- Common confusion
- Choosing an after rule with current.update() to change the same record, or using an async rule when the user must see the result immediately.
6.3 System update setsCapturing configuration and moving it between instances.
- What it means
- An update set is a container that records configuration changes, such as form layouts, business rules, ACLs and dictionary entries, made while it is the user's current update set, so they can be moved from one instance to another.
- What to understand
- The migration flow is: make changes in the current update set in the source, mark it Complete, retrieve it in the target (from a remote instance or as an XML file), preview it, resolve any problems or collisions, then commit. Update sets capture configuration, not ordinary data such as incidents or users, keep only the latest version of each changed record, and are tracked per application scope.
- How it shows up
- A preview shows a problem because a newer version of the same item exists on the target, and you decide whether to accept or skip the remote update before committing.
- Common confusion
- Expecting update sets to carry data records, or committing without previewing and resolving problems first.
6.4 Scripting in ServiceNowClient and server scripts, GlideRecord and reusable code.
- What it means
- Client scripts run in the browser on form events (onLoad, onChange, onSubmit and onCellEdit for lists) and use g_form and g_user. Server scripts run in business rules, Script Includes, scheduled jobs and server-side UI actions, using GlideRecord to query and change records and GlideSystem (gs) for messages, user details, events and logging.
- What to understand
- GlideRecord follows a pattern: create the object for a table, add query conditions, call query(), then loop with next() to read or update records. Script Includes hold reusable server code that other server scripts call, and they can be called from the client through GlideAjax when marked client callable. The platform's guidance is to use no-code options first and script only when configuration cannot meet the need.
- How it shows up
- A short script is shown and you identify whether it runs on the client or the server, or what a GlideRecord query returns.
- Common confusion
- Using g_form in a business rule or GlideRecord queries in client scripts, which mixes client and server APIs.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
UI policy action
The part of a UI policy that sets a specific field to mandatory, visible or read-only, or leaves a setting alone.
- Remember
- Each action targets one field and can set any combination of the three properties.
- Tested as
- Questions on conditional field behaviour use these properties by name.
- Trap
- Expecting UI policy actions to set field values, which needs a script or client script.
-
Reverse if false
A UI policy option that undoes its actions when the condition stops being true.
- Remember
- Without it, a field made mandatory stays mandatory after the condition changes back.
- Tested as
- Explains why a field stays mandatory after a value is changed.
- Trap
- Thinking UI policies reverse automatically.
-
Data policy
A server-side rule that enforces mandatory and read-only fields for all data sources, including imports and web services.
- Remember
- It can also be applied on forms as a UI policy, and a UI policy can be converted to one.
- Tested as
- The answer when a requirement must hold outside the form.
- Trap
- Choosing a UI policy for integration data.
-
Client script types
onLoad runs when a form opens, onChange when a field changes, onSubmit when the form is saved, and onCellEdit when a list cell is edited.
- Remember
- onSubmit can return false to stop the save.
- Tested as
- Recall questions name the event and expect the type.
- Trap
- Using onLoad for logic that must react to a later field change.
-
Before business rule
Runs before the record is written to the database, so changes to current are saved with it.
- Remember
- Do not call current.update() in it.
- Tested as
- The answer for setting values on the record being saved.
- Trap
- Choosing an after rule plus current.update().
-
After business rule
Runs after the record is saved, typically to update related records or log follow-up actions.
- Remember
- Changes to the same record here need another save, so use before rules for that.
- Tested as
- The answer for updating child or related records immediately.
- Trap
- Using it to modify the triggering record.
-
Async business rule
Runs after the save as a background job so the user does not wait.
- Remember
- Suited to slow work such as calling external systems; the previous object is not available.
- Tested as
- The answer when processing must not slow down the user's save.
- Trap
- Choosing it when the user needs the result shown immediately.
-
Display business rule and g_scratchpad
A display rule runs before a form loads and can place server data in g_scratchpad for client scripts.
- Remember
- It avoids extra server calls from the client.
- Tested as
- Appears when a client script needs server-side information on load.
- Trap
- Using GlideRecord in a client script instead.
-
Update set lifecycle
Capture changes in a current update set, mark it Complete, retrieve it in the target, preview, resolve problems, then commit.
- Remember
- Preview is required before commit and surfaces collisions and missing dependencies.
- Tested as
- Sequencing and next-step questions follow this order.
- Trap
- Committing straight after retrieval.
-
What update sets capture
Configuration records such as forms, lists, dictionary entries, business rules, ACLs and notifications.
- Remember
- Ordinary data such as incidents, users and group memberships is not captured and must be moved another way, for example by exporting XML.
- Tested as
- Questions ask why something did not arrive in the target instance.
- Trap
- Expecting test records to travel with the configuration.
-
Default update set
The update set used when no other is selected as current.
- Remember
- Changes meant for migration should be made in a named update set, chosen before you start work.
- Tested as
- Explains why changes are missing from the update set that was migrated.
- Trap
- Forgetting to switch the current update set before configuring.
-
GlideRecord
The server-side API for querying, inserting, updating and deleting records in a table.
- Remember
- Pattern: new GlideRecord(table), addQuery or addEncodedQuery, query(), then while next().
- Tested as
- Script-reading questions use this pattern.
- Trap
- Using it in client scripts, where it is discouraged and should be replaced by GlideAjax or g_scratchpad.
-
Script Include
A reusable server-side script, usually a class, called by other server scripts.
- Remember
- Marking it client callable allows client scripts to call it through GlideAjax.
- Tested as
- The answer for logic shared across several business rules.
- Trap
- Copying the same code into several business rules.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
UI policy vs. client script vs. data policy
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| UI policy | No-code form rule for mandatory, visible and read-only | Client-side on forms only | Relying on it for imports or integrations |
| Client script | Scripted browser logic on form events | Can set values, validate and call the server | Using it where a UI policy suffices |
| Data policy | Server-side mandatory and read-only enforcement | Applies to all data sources | Expecting it to hide fields |
Before vs. after vs. async vs. display business rules
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Before | Runs before the database write | Changes to current are saved without update() | Calling current.update() |
| After | Runs after the write | Best for updating related records immediately | Changing the same record here |
| Async | Runs after the write as a background job | User does not wait; previous is unavailable | Expecting immediate visible results |
| Display | Runs before a form is shown | Fills g_scratchpad for client scripts | Using it to change saved data |
Client-side vs. server-side scripting
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Client-side | Client scripts, UI policy scripts, catalog client scripts | Run in the browser with g_form and g_user | Using GlideRecord or gs |
| Server-side | Business rules, Script Includes, scheduled jobs, server UI actions | Run on the instance with GlideRecord, gs, current and previous | Using g_form |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Form rule for all data
- What candidates pick
- A UI policy to make a field mandatory for records created by an integration.
- Why it looks right
- UI policies are the standard no-code way to make fields mandatory.
- Why it's wrong
- UI policies act only on forms; a data policy enforces the rule for imports, web services and forms.
Clue to watch for The stem mentions integrations, imports, web services or 'regardless of how the record is created'.
-
After rule to set own field
- What candidates pick
- An after business rule that sets a field and calls current.update().
- Why it looks right
- The record exists by then, so updating it seems safe.
- Why it's wrong
- It causes a second save and can trigger rules again; a before rule sets the value in the same write.
Clue to watch for The value belongs on the same record being saved.
-
Async for instant feedback
- What candidates pick
- An async business rule to show a calculated value as soon as the user saves.
- Why it looks right
- Async is described as efficient.
- Why it's wrong
- Async rules run later in the background, so the user may not see the result on save.
Clue to watch for The user must see the change immediately.
-
Commit without preview
- What candidates pick
- Commit a retrieved update set right away to save time.
- Why it looks right
- The changes were tested in the source instance.
- Why it's wrong
- Preview is required to detect collisions and missing dependencies, which must be resolved before committing.
Clue to watch for The next step after retrieving an update set is asked.
-
Data in update sets
- What candidates pick
- Expect sample incidents and new users to arrive with the update set.
- Why it looks right
- They were created during the same piece of work.
- Why it's wrong
- Update sets capture configuration, not ordinary data records, which must be moved separately.
Clue to watch for Records missing in the target are data such as tasks, users or group members.
-
Client script where a UI policy works
- What candidates pick
- An onChange client script to make a field read-only when State changes.
- Why it looks right
- Scripts feel flexible and precise.
- Why it's wrong
- A UI policy does this without code and is easier to maintain, which the exam prefers.
Clue to watch for The behaviour is only mandatory, visible or read-only.
-
Wrong current update set
- What candidates pick
- Assume all changes were captured in the named update set.
- Why it looks right
- The admin created the update set before starting.
- Why it's wrong
- Changes are captured only in the user's current update set; work done while Default was current is not in the named set.
Clue to watch for Some configuration is missing after migration.
Answer framework
Use these steps to choose the right logic or migration action in this domain.
- Decide where the behaviour must happen: on the form only, or for every way data enters the table, which separates UI policies from data policies and business rules.
- If it is form-only and limited to mandatory, visible or read-only, choose a UI policy; use a client script only when values or validation need code.
- For server logic, choose the timing: before for the same record, after for related records, async for slow background work, display for form data.
- Put shared server code in a Script Include and keep client and server APIs on their own side.
- For migration, confirm the current update set, mark it Complete, retrieve, preview, resolve problems, then commit, moving data records separately.
Practice question
Want more like this? The ServiceNow CSA practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with UI policies and data policies, because they are no-code and set up the client-versus-server idea the rest of the domain depends on. Build a UI policy that makes a field mandatory on a condition, test it with and without Reverse if false, then try to bypass it by editing in a list and see a data policy stop you.
Next, learn business rule timing by building four small rules on a test table, one for each of before, after, async and display, and watching their effects. Read the current and previous objects in the script field and note what each timing can safely change.
Candidates underestimate update sets until they see a preview problem. Use two Personal Developer Instances if you can, or export and import an update set as XML: make a change, complete it, retrieve it, preview it, and resolve a collision.
For scripting, focus on reading, not writing: GlideRecord queries, g_form calls and gs methods. Afterwards, return to Database Management and Platform Security for a final pass on ACLs, then take a full timed mock exam.
FAQ
Do I need to be a developer to pass this domain?
No. You need to read simple scripts, know where each script type runs and choose the right timing. Writing complex code is the focus of the Certified Application Developer exam, not the CSA.
Why is this domain called Data Migration and Integration when it covers UI policies and business rules?
That is the name ServiceNow gives the domain, and its objectives are UI policies, business rules, update sets and scripting. Study the objectives rather than the title.
What is the difference between a UI policy and a data policy?
A UI policy controls fields on forms in the browser, while a data policy enforces mandatory and read-only rules on the server for every data source. A data policy can also be applied to forms as a UI policy.
Which business rule should change the record being saved?
A before business rule, because changes to current are saved in the same write. After rules are for related records, and calling current.update() in them is discouraged.
Do update sets move users and groups?
No. Update sets carry configuration, and ordinary data such as users, group memberships and tasks must be moved another way, for example by exporting and importing XML.
How many questions are in this domain?
At 13% of 60 questions, plan for about eight. ServiceNow does not publish per-domain question counts, so treat this as a planning estimate.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 6 knowledge
You have covered UI policies, business rule timing, update set migration and scripting basics. Check that you can spot client versus server and before versus after under exam conditions.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ServiceNow CSA AI tutor Get any concept explained your way