ServiceNow Update Sets &

Deployment
Complete Expert Guide + Interview Q&A
Update Sets, Batch Update Sets, Instance topology, cloning,
conflict resolution, back-out strategies, CI/CD pipeline integration,
and 12+ expert interview Q&A for senior admins and developers.

For ServiceNow Professionals with 6+ Years Experience

ServiceNow Update Sets & Deployment — Complete Expert Guide + Interview Q&A Page 2

PART 1 — Update Sets & Deployment Complete Guide

1. What Update Sets capture — and what they don't

Captured in Update Sets NOT captured

Business Rules, Client Scripts, Script Includes Data records (user accounts, incident records)

UI Policies, UI Actions, Notifications User preferences and personalised views

Form layouts, List views, Field labels Scheduled Job execution history

ACLs, Roles, Role assignments to groups System logs

Catalog items, Variables, Workflows, Flows Properties set to instance-specific values

Report definitions, Dashboard configs Attachments on records

Import Sets, Transform Maps Import Set data (staging table rows)

Dictionary entries (new fields, tables) ATF test results

2. Complete deployment workflow — Dev to Test to Production

Step-by-step: Dev -> Test -> Production with best practices

■■ DEV INSTANCE ■■

1. Navigate: System Update Sets > Local Update Sets > New

Name: 'JIRA-4521 — Add Backup Approver field to Incident'

Description: Link to Jira ticket + brief change summary

Application: Global (or your scoped app)

2. Click 'Make Current' — this is now your active Update Set

Verify in top-right corner: 'Update Set: JIRA-4521 — Add Backup...'

IMPORTANT: make this a habit before ANY config change

3. Make ALL related changes:

- Add field to Incident table (Dictionary entry)

- Add field to form layout

- Add field to relevant list views

- Create/update Business Rule for field logic

- Create/update ACL if field needs access control

- Create/update Notification if field triggers emails

4. Review captured artifacts:

Open Update Set > 'Customer Updates' related list

Verify ALL expected artifacts are listed (no missing pieces)

If an artifact is missing: make a trivial change to it (add a space

to description, save, revert) — this forces capture

[Link] | [Link] | [Link] Update Sets Expert Reference

ServiceNow Update Sets & Deployment — Complete Expert Guide + Interview Q&A Page 3

5. Complete the Update Set: open record > click 'Complete'

State changes from 'In Progress' to 'Complete'

6. Export: right-click the Update Set in list > 'Export to XML'

Save as JIRA-4521_dev_to_test.xml

■■ TEST INSTANCE ■■

7. Navigate: System Update Sets > Retrieved Update Sets > Import Update Set from XML

8. Upload the XML file > state becomes 'Loaded'

9. Open the Retrieved Update Set > Click 'Preview Update Set'

ServiceNow checks every artifact for conflicts with existing config

10. Review Preview Results:

Green = No conflict — safe to commit

Yellow = Overwrite warning — existing customisation will be replaced

Red = Error — must fix before committing

11. For Yellow/Red: click into the conflict, review the diff,

choose: Accept Remote (your change wins) or Skip (keep existing)

12. Click 'Commit Update Set' — changes go live on Test

13. Run your ATF test suite against Test instance

14. UAT sign-off from business stakeholders

■■ PRODUCTION INSTANCE ■■

15. Repeat steps 7-12 on Production

16. Smoke test: manually verify the key functionality works

17. Mark Update Set 'Complete' for audit history

3. Batch Update Sets — deploying related changes in order

When multiple Update Sets have dependencies (Set B requires Set A's new table to exist before it can add a field to it), use
Batch Update Sets to ensure correct deployment order.

// Navigate: System Update Sets > Batch Update Sets > New

// Name: 'Sprint 12 — Vendor Risk Module'

// Description: Complete Sprint 12 release including all 4 stories

// Add Update Sets in dependency order:

// Order 10: JIRA-4510 — Create Vendor Risk tables (tables first!)

// Order 20: JIRA-4511 — Add Vendor Risk fields and dictionary

// Order 30: JIRA-4512 — Vendor Risk Business Rules and ACLs

// Order 40: JIRA-4513 — Vendor Risk Service Portal widget

// When you commit the Batch Update Set, ServiceNow commits

// the individual sets IN ORDER — ensuring table exists before

// fields are added, fields exist before BRs reference them, etc.

[Link] | [Link] | [Link] Update Sets Expert Reference

ServiceNow Update Sets & Deployment — Complete Expert Guide + Interview Q&A Page 4

// To export a Batch as one file:

// Batch Update Set record > Export to XML

// This creates ONE XML file containing ALL member sets in order

4. Conflict resolution — expert guide

Conflict type Cause Resolution strategy

Field value conflict Target has different value in same field as Review both versions; accept the one correct for
your Update Set production

Deleted record conflict Record was deleted in target but exists in Usually: accept remote (recreate the record)
your Update Set

Different base record Same sys_id but different name/type — Investigate: may need manual recreation rather
usually a data issue than commit

Dependency missing Update Set references a record that doesn't Identify the missing record and either import it or fix
exist in target the reference

Version conflict Target has newer version of same artifact Review changes carefully — your Update Set may
overwrite valuable fixes

5. CI/CD pipeline integration with Update Sets

// ■■ Automated Update Set deployment via ServiceNow REST API ■■■■■

// Step 1: Export Update Set from Dev (via REST)

GET /api/now/table/sys_update_set?

sysparm_query=name=JIRA-4521^state=complete

&sysparm_fields=sys_id,name,state

// Step 2: Download the XML

GET /api/now/table/sys_update_xml?

sysparm_query=update_set={sys_id from step 1}

// Step 3: Upload to Target instance

POST /api/now/table/sys_update_xml

Body: { 'action': 'load', 'payload': '<xml content here>' }

// Step 4: Preview the Update Set

POST /api/now/table/sys_remote_update_set/{retrieved_set_sys_id}

Body: { 'state': 'previewed' }

// Poll until state = 'previewed'

// Step 5: Check for conflicts

GET /api/now/table/sys_update_preview_problem?

sysparm_query=remote_update_set={retrieved_set_sys_id}

// If any problems with type='error' -> FAIL the pipeline

// Step 6: Commit (only if no errors)

POST /api/now/table/sys_remote_update_set/{retrieved_set_sys_id}

Body: { 'state': 'committed' }

// Full pipeline: Jenkins/Azure DevOps calls these APIs automatically

// after a PR is merged to main branch — zero-touch deployment

[Link] | [Link] | [Link] Update Sets Expert Reference

ServiceNow Update Sets & Deployment — Complete Expert Guide + Interview Q&A Page 5

PART 2 — Update Sets Interview Q&A

Q1 What does an Update Set capture and what does it NOT capture? Fresher

Update Sets capture CONFIGURATION changes: Business Rules, Client Scripts,

Script Includes, UI Policies, ACLs, Form layouts, Notifications, Catalog

items, Workflows, Flows, Dictionary entries (new fields and tables),

Reports, and Scheduled Jobs. They do NOT capture: DATA records (incidents,

users, CI records), user preferences, system logs, attachment files,

execution history, or instance-specific property values (like SMTP settings

that differ per environment). This is why you need separate data migration

scripts for data, and why you must re-set instance-specific properties

in each environment after deployment.

Q2 A Update Set commit in Production failed halfway through. How do you recover? Senior

First: do NOT attempt to commit the same Update Set again immediately —

partial commits can create inconsistent state. Check: 1) What was the

specific error? View the commit log in the Update Set's related list.

2) Which artifacts committed successfully before the failure? Those changes

are live. 3) Which artifacts didn't commit? Those are not applied yet.

Recovery options: A) Fix the root cause of the failure (often a missing

dependency or a script error), then retry the commit — ServiceNow usually

handles re-committing already-committed artifacts safely (idempotent for

most artifact types). B) If you can't fix quickly: manually apply the

missing artifacts one by one via direct configuration. C) If the partial

commit caused problems: initiate a back-out of the committed portion

(note: back-out is not always reliable — having a prod backup is critical).

Q3 What are Batch Update Sets and when would you use them? Mid

Batch Update Sets group multiple individual Update Sets into a single

deployable package with a defined commit order. Use them when: your sprint

has multiple Update Sets with dependencies (Set B's Business Rule references

a table created in Set A — you must commit A before B), you want to deploy

a complete feature as one atomic operation, or you need to ensure a team's

[Link] | [Link] | [Link] Update Sets Expert Reference

ServiceNow Update Sets & Deployment — Complete Expert Guide + Interview Q&A Page 6

individual Update Sets always deploy together and in the right order.

Without Batch, deploying 5 related Update Sets in the wrong order breaks

the deployment. With Batch: one XML export, one import, guaranteed order.

CODING: Write a background script that lists all Update Sets created in the last 7
Q4 Coding
days and their artifact counts.

var us = new GlideRecord('sys_update_set');

[Link]('sys_created_on', '>=', [Link](7));

[Link]('application', 'Global'); // or filter by scope

[Link]('sys_created_on');

[Link]();

while ([Link]()) {

// Count artifacts in this Update Set

var artifacts = new GlideAggregate('sys_update_xml');

[Link]('update_set', [Link]());

[Link]('COUNT');

[Link]();

var count = [Link]() ? [Link]('COUNT') : 0;

[Link](

[Link]('name') + ' | ' +

[Link]('state') + ' | ' +

count + ' artifacts | ' +

'Created by: ' + us.sys_created_by.getDisplayValue()

);

[Link] | [Link] | [Link] Update Sets Expert Reference