Update Sets | ServiceNow CSA Part 5

Section 1

What Update Sets Do

Update Sets are ServiceNow's built-in mechanism for moving configuration changes between instances — typically from a Development environment to Test, then to Production. They act as a container that records every metadata change made while they are active.

Most Important Concept: Update Sets capture CONFIGURATION, not DATA. They do not transport incident records, user records, or any transactional data. They capture only metadata — scripts, forms, workflows, rules, and similar platform configuration objects.

The Two Core Tables

📋

sys_update_set

Stores the update set container — the metadata about the update set itself: its name, state, description, application scope, and who created it.

Think of this as the "folder" that holds all the changes.

🗂️

sys_update_xml

Stores the individual captured changes — each row is one configuration change recorded inside an update set. The actual XML payload of each change lives here.

Think of this as each individual "file" inside the folder.

Purpose: Controlled Promotion Path

The primary use case for update sets is promoting configuration changes through a defined pipeline so that untested changes never reach production directly.

DEV Instance ──── export XML ────▶ TEST Instance ──── export XML ────▶ PROD Instance

Configuration changes flow through environments via Update Set XML files

Why Not Just Configure PROD Directly? Configuring production directly is risky — changes can break live services. Update Sets enforce a workflow: develop in a sandbox, test in a staging environment, then promote to production only after validation.

Section 2

Update Set States

Every update set exists in one of four states. Understanding the lifecycle of an update set — and what each state means — is essential for the exam.

State	Meaning	What You Can Do
In Progress	The update set is active and capturing changes. Any configuration changes made while this is the current update set are recorded here.	Add changes, set as current, rename, add description
Complete	The update set has been closed. No new changes will be added. It is now ready to be exported as an XML file.	Export to XML, reopen (set back to In Progress)
Loaded	The update set has been imported into a target instance (from an XML file) and is pending preview and commit. This state only exists on the receiving instance.	Preview, Commit, or mark as Ignore
Ignore	The update set has been explicitly marked to skip. It will not be committed to the instance. Used when a loaded update set is not needed or superseded.	Reopen as Loaded to revisit

Exam Sequence: Remember the state flow: In Progress → Complete → (export XML) → Loaded → Commit. You cannot export an "In Progress" update set — it must be set to Complete first. This is a commonly tested trap question.

Section 3

What Gets Captured (and What Does Not)

Knowing exactly what is and is not captured by update sets is one of the most frequently tested topics. The rule is straightforward: configuration (metadata) yes, data (records) no.

Captured — Configuration Objects

Scripting

Business Rules
Client Scripts
Script Includes
Scheduled Jobs (Scheduled Scripts)
Fix Scripts

Form & UI

Form layouts (sys_ui_view)
UI Policies
UI Actions
Dictionary entries (custom fields)
List layouts

Security & Access

ACLs (Access Control rules)
Roles (custom roles)
System properties (sys_properties)

Notifications & Email

Notification rules
Email templates
Inbound email actions

Service Catalog

Catalog items
Catalog variables
Order guides
Record producers

Process Automation

Workflows (legacy)
Flow Designer flows (partially)
SLA definitions
Assignment rules

NOT Captured — Data Records

What Update Sets Will NEVER Capture:

Incident, Problem, Change records — transactional ITSM data
User records (sys_user) — account data, profiles
Group records (sys_user_group) — group memberships
CMDB records — configuration items and relationships
Attachments — file uploads on records
Import set data — staging table contents

To move data between instances, use Data Migration, Import Sets, or XML data exports — not update sets.

Flow Designer Caveat: Flow Designer flows are partially captured by update sets (the flow definition itself is captured), but any action configurations that reference specific record sys_ids in the target environment may break if those records don't exist there. Always validate after committing flows.

Section 4

Update Set Workflow — End to End

The full update set workflow spans two instances: the source (where changes are made) and the target (where changes are applied). Each step must be performed in the correct order.

Phase 1: Capture Changes on DEV

Step	Action	Where
1	Navigate to System Update Sets › Local Update Sets and create a new update set (give it a clear name)	DEV — top right corner or nav
2	Click "Set as Current" — the update set name now appears in the top-right header bar of the instance	DEV — update set record form
3	Make all configuration changes (create business rules, modify forms, build workflows, etc.)	DEV — anywhere in the instance
4	Navigate back to the update set and change its State to "Complete" — this closes it to new changes	DEV — update set record

Phase 2: Export from DEV

Step	Action
5	Open the completed update set and click "Export to XML" — downloads a `.xml` file to your computer. This file is stored as a sys_remote_update_set record.

Phase 3: Import and Apply on TARGET (TEST or PROD)

Step	Action	Notes
6	Navigate to System Update Sets › Retrieved Update Sets and click "Import Update Set from XML"	TARGET instance
7	Upload the exported `.xml` file. The update set appears with state Loaded	TARGET — file upload dialog
8	Click "Preview Update Set" — ServiceNow checks for conflicts and missing dependencies	TARGET — ALWAYS do this before commit
9	Review any Preview Problems. Resolve issues (accept remote version, skip, or fix manually)	TARGET — review each problem row
10	Click "Commit Update Set" — applies all changes to the target instance	TARGET — this is irreversible without backout

Critical Exam Sequence — Memorize This:
Set Current → Make Changes → Complete → Export XML → Import → Preview → Commit
Any question asking about the order of steps in an update set workflow maps to this sequence. "Preview" always comes before "Commit" — never skip it.

Section 5

Preview and Commit — Conflict Resolution

Preview is the most important safety gate in the update set process. It identifies problems before changes are applied to a live or production instance — making it possible to resolve conflicts without risk.

What Preview Checks For

Missing Parent Records

A change depends on a parent record that does not exist in the target. For example, a business rule references a table that hasn't been created on the target instance.

Resolution: ensure the parent object exists before committing.

Conflicting Changes

The same configuration object was modified on both the source and the target since the last sync. Preview shows both versions and lets you choose which to keep.

Resolution: accept remote (from update set) or keep current (target version).

Deleted on Target

An object in the update set was already deleted from the target instance. The update set is trying to modify something that no longer exists.

Resolution: skip the change or recreate the base object.

Scope Mismatches

The application scope of a change doesn't align with an installed application on the target instance. Scoped app changes require the app to be present.

Resolution: install the application scope on the target first.

Preview Problem Resolutions

Resolution Option	Meaning	When to Use
Accept Remote	Use the version from the incoming update set (overwrite what's on target)	The source DEV version is the correct one to use
Skip	Do not apply this particular change — leave the target as-is for this object	The target version is correct, or the change is not needed here
Accept Local	Keep the target instance's current version for this object	Equivalent to Skip in most scenarios

Commit and Backout

Committing applies all previewed changes to the target instance. Once committed, changes take effect immediately — there is no undo button. However, ServiceNow provides a Backout mechanism.

Backout — Not a True Undo: A committed update set can be backed out, which reverses the changes it applied. However:

Backout only works if no subsequent changes have been made to the same objects
Backout restores the state at the time of commit — any work done after the commit on those objects may be lost
It is not a guaranteed rollback — it is a best-effort reversal
You cannot uncommit an update set — only back it out

Exam Fact: The exam distinguishes between "uncommit" (does not exist) and "backout" (the correct term for reversing a committed update set). If a question says "you need to uncommit an update set," the correct answer involves Backout, not an uncommit operation.

Section 6

Batch Update Sets

Batch Update Sets allow multiple related update sets to be grouped and deployed together as a single unit. This is critical for feature development where changes are spread across several individual update sets.

Parent and Child Structure

📁

Parent Update Set

The container that holds child update sets. The parent itself may contain changes, or it may be an empty container used only for grouping purposes.

Committing the parent commits all children in the correct order.

📄

Child Update Sets

Individual update sets that belong to a parent. Each child captures a subset of the overall feature's changes — for example, one per developer working on the same feature.

Children can be merged into the parent before deployment.

Merge Operation

Children can be merged into the parent update set to consolidate all changes into a single deployable unit. This simplifies the deployment process — one import and one commit instead of many.

Use Case Example: A feature requires: (1) a new custom table, (2) a business rule on that table, and (3) a catalog item. Three developers work in parallel, each with their own update set. A parent update set is created to group all three. Before deployment to TEST, all three children are merged into the parent, producing a single XML export containing all the changes.

Order Matters: When merging children, consider dependency order. If update set B depends on a change made in update set A, A must be committed first. Define the correct commit order when using batch update sets to avoid preview conflicts.

Section 7

The Default Update Set

Every ServiceNow instance has a system-provided update set called "Default". It is always present and acts as the fallback capture container when no other update set has been set as current.

How Default Works

The Default update set is always "In Progress" — it cannot be completed or deleted
If a user makes configuration changes without first selecting a specific update set, those changes go into Default
The current update set is always shown in the top-right corner of the ServiceNow instance header
If the header shows "Default" — changes are going into the Default update set

Best Practice — Avoid Default in Production Workflows: Using the Default update set for real changes is not recommended. Because the Default set accumulates random unrelated changes from anyone who forgets to set a current update set, it becomes messy and unmanageable. Always create a named update set for each feature or change task.

Scenario	What Happens	Recommendation
No update set is set as current	Changes are silently captured in the Default update set	Always set a named update set as current before working
Developer forgets to switch update sets	Changes go to Default — mixed with other unrelated changes	Check the top-right header before making any changes
Trying to export Default set	Must first set it to Complete — but this blocks all future "accidental" captures	Avoid relying on Default; use named sets from the start

Section 8

Global Scope vs. Application Scope Update Sets

ServiceNow distinguishes between changes made in the global application scope and changes made within a scoped application. Update sets operate differently depending on the scope context.

Global Scope

All platform-level customizations (not inside a scoped app) are in the Global scope
Global update sets capture changes to any global-scope configuration object
Most CSA exam scenarios involve global scope update sets
Created and managed via System Update Sets › Local Update Sets

Application Scope

Scoped applications (built with the Application Development framework) use their own update sets
Changes inside a scoped app are automatically captured by that app's update set
You cannot mix global and scoped changes in the same update set
Scoped app deployment is often handled through the Application Repository or Store rather than manual update set exports

Exam Scope Distinction: If a question mentions a custom scoped application, updates to that app's configuration are managed via the app's own update set mechanism. Global update sets capture changes made directly in the global scope — not inside a scoped application's namespace.

Aspect	Global Scope	Application Scope
Where changes live	Platform-wide configuration tables	Scoped app-specific tables and records
Update set type	Standard global update set	Application-scoped update set
Can they mix?	No — global and scoped changes cannot share an update set
CSA exam focus	Primary focus	Awareness only — not deep-dived at CSA level

Section 9

Key Exam Facts & Traps

This section consolidates every critical, frequently tested fact about update sets. Review this list before your exam.

Trap 1 — Config Not Data: Update sets capture configuration (metadata) only. They do NOT capture data records such as incidents, users, or CMDB items. If a question implies moving incident records via update sets, the answer is incorrect — use Import Sets or XML exports for data.

Trap 2 — Must Complete Before Export: You cannot export an In Progress update set. The state must be set to Complete before the "Export to XML" option becomes available. A question asking "what must happen before export" → answer: set state to Complete.

Trap 3 — Preview Before Commit: The correct workflow is always Preview first, then Commit. Preview identifies conflicts and missing dependencies before changes are applied. Skipping preview risks breaking the target environment. The exam tests this sequence explicitly.

Trap 4 — sys_update_xml Stores Changes: The table sys_update_xml stores the individual captured changes (each row = one configuration change). The table sys_update_set stores the container/header. Know both table names — the exam uses them.

Trap 5 — Current Update Set in Top-Right: The currently active update set is always shown in the top-right corner of the instance header. If the header shows "Default," changes are going into the Default update set — not a named one. This is where developers check before making changes.

Trap 6 — No Uncommit, Only Backout: Once committed, an update set cannot be uncommitted. The only reversal mechanism is Backout, which attempts to restore the prior state. Know the terminology: "backout" not "uncommit" or "rollback."

Trap 7 — Loaded State is Import-Only: The Loaded state only exists on the target/receiving instance after XML import. An update set on the source instance is never in "Loaded" state — it is either In Progress, Complete, or Ignore.

Quick-Reference Summary

Update Sets capture:   CONFIG (metadata), NOT data
States:               In Progress → Complete → Loaded → Committed
Export format:        XML file (sys_remote_update_set)
Individual changes:   sys_update_xml table
Container/header:     sys_update_set table
Current set shown:    Top-right corner of the instance header
Must do before export: Set state to COMPLETE
Must do before commit: Run PREVIEW first
Reversing a commit:   BACKOUT (not uncommit)
Default update set:   Always exists, always In Progress, not for prod use
Global vs Scoped:     Cannot mix in same update set

Putting It All Together — The Full Story:

A developer on DEV creates a named update set and sets it as current (visible top-right)
All configuration changes made are automatically captured in sys_update_xml under that update set
When done, the developer sets the update set to Complete and exports it as an XML file
A release manager imports the XML into the TEST instance — the set appears as Loaded
Preview is run to check for conflicts or missing dependencies
Issues are resolved, then the update set is Committed — changes are applied to TEST
After successful testing, the same XML is imported and committed to PROD