ServiceNow Update Sets
Update Sets are the mechanism for moving configuration changes between ServiceNow instances — from Development to Test to Production. Every time an administrator or developer makes a configuration change in DEV, ServiceNow records that change in the current Update Set. The Update Set is then exported and imported into the next environment, applying the changes there without manual re-configuration.
Why Update Sets Exist
WITHOUT Update Sets: Dev builds a new workflow in DEV instance → Must manually recreate it in TEST → Must manually recreate it again in PROD → Human error guaranteed → Hours of repeated work WITH Update Sets: Dev builds the workflow in DEV → Export the Update Set (one file) → Import into TEST → Preview → Commit → Import into PROD → Preview → Commit → Zero manual recreation, exact copy every time
What Gets Captured in an Update Set
Most configuration changes made through the ServiceNow interface are automatically captured. These include:
- Business Rules, Client Scripts, UI Policies
- Workflows and Flow Designer flows
- Script Includes and Scripted REST APIs
- Form layouts and list configurations
- Notifications and email templates
- Service Catalog items and variables
- ACL rules and roles
- Reports and dashboards (when explicitly added)
Data records — incident tickets, user accounts, actual transactions — are not captured in Update Sets. Update Sets carry configuration and code, not operational data.
The Update Set Workflow
Step 1: Create and Activate an Update Set in DEV
Navigate to System Update Sets > Local Update Sets and click New. Give it a descriptive name like "Incident Form — Priority Auto-Set v1.2." Click the Update Set name in the breadcrumb to set it as the current active Update Set. From this point forward, every configuration change gets recorded here.
Step 2: Make Configuration Changes
Build the feature — create the Business Rule, configure the form, build the workflow. Every change registers in the active Update Set automatically. No manual action needed during development.
Step 3: Complete the Update Set
When development is finished, open the Update Set record and change its State from "In Progress" to "Complete." This locks the Update Set — no further changes are added to it. Changes after this point go into the next Update Set.
Step 4: Export the Update Set
From the completed Update Set record, click "Export to XML." ServiceNow downloads an XML file containing all recorded changes. This file is the portable package that moves to the next environment.
Step 5: Import into TEST
In the TEST instance, navigate to System Update Sets > Retrieved Update Sets and click Import Update Set from XML. Upload the XML file. ServiceNow registers the Update Set in TEST.
Step 6: Preview the Update Set
Click Preview Update Set. ServiceNow analyzes every change in the Update Set and checks for conflicts — changes that would overwrite a record that was modified differently in TEST. Review the preview results carefully. Resolve any conflicts before proceeding.
Step 7: Commit the Update Set
After a clean preview, click Commit Update Set. ServiceNow applies all changes to the TEST instance. The same import-preview-commit sequence repeats when promoting to PROD.
Full Update Set Promotion Path:
DEV: Create → Develop → Complete → Export XML
↓
TEST: Import XML → Preview → Resolve conflicts → Commit
↓
PROD: Import XML → Preview → Resolve conflicts → Commit
Handling Update Set Conflicts
A conflict occurs when the Update Set tries to apply a change to a record that was already modified differently in the target instance. For example, a Business Rule was edited in both DEV and TEST independently. Preview shows this conflict as a warning. The developer reviews both versions and decides which one should win before committing.
Merging Update Sets
When multiple developers work on different Update Sets simultaneously, an administrator merges them into one before promotion. Navigate to the Update Set list, select multiple completed Update Sets, and use the Merge action. ServiceNow creates a single new Update Set containing all changes from the selected sets — simplifying the promotion process to one package instead of many.
Update Set Best Practices
- Name Update Sets clearly — include the feature name, version, and date.
- Use one Update Set per feature or bug fix. Mixing unrelated changes into one Update Set makes rollback impossible.
- Always preview before committing in PROD — treat the preview step as mandatory, never optional.
- Keep a change log documenting what each Update Set contains and which environments it has been applied to.
- Do not make emergency changes directly in PROD without capturing them in an Update Set — back-port the change to DEV immediately after to keep environments in sync.