Admin

Update Sets in ServiceNow: Complete Guide to Moving Changes Between Instances

Update Sets are the primary mechanism for moving configuration changes from development to test to production in ServiceNow. They are simple in concept but full of edge cases that cause production incidents for developers who do not know the details. This guide covers everything: what gets captured, the complete workflow, conflict resolution, merging, common mistakes, and best practices.

What is an Update Set?

An Update Set is a container that captures configuration changes made to a ServiceNow instance. When you edit a Business Rule, create a Script Include, modify a form layout, or build a flow, those changes are recorded in the currently active Update Set. The Update Set can then be exported to XML and imported into another instance.

What Update Sets capture

Update Sets capture configuration records — not data. The key distinction:

  • Captured: Business Rules, Script Includes, Client Scripts, UI Policies, UI Actions, Flow Designer flows, actions and subflows, Form layouts and views, ACLs and roles, Catalog items and variables, Scheduled Jobs, Application menus and modules, Dictionary entries, Notifications
  • NOT captured: Incident, Problem, Change records; User records and group memberships; Assignment rules; System properties (need manual transfer or separate Update Set); Application data records

This distinction is the most important thing to understand about Update Sets. If you make data changes (update an incident, create a user, change a system property) those do not appear in your Update Set.

Setting the current Update Set

Always set your current Update Set before making changes. Go to the Update Set picker at the top-right of the developer instance UI, or navigate to System Update Sets > Local Update Sets and mark yours as Current.

If you forget to set one, changes go into Default — which becomes a maintenance nightmare when you need to isolate changes for a specific release. Default Update Sets should never be promoted to production.

The complete Update Set workflow

Development Instance:
1. Create new Update Set (System Update Sets > Local Update Sets > New)
2. Set as Current Update Set
3. Make your configuration changes (all captured automatically)
4. Mark Update Set as Complete
5. Export: right-click the Update Set > Export to XML

Test Instance:
1. System Update Sets > Retrieved Update Sets > Import XML
2. Preview the Update Set — check for conflicts and errors
3. If preview clean: Commit the Update Set
4. Test all changes

Production Instance:
1. Repeat import, preview, commit from test
2. Verify in production

The preview step — never skip it

Previewing an Update Set before committing checks for:

  • Conflicts — the same record was modified in both the source and target instances. The preview shows you which side is newer.
  • Missing references — the Update Set references a record (a Script Include, a table, a field) that does not exist in the target instance
  • Errors — records that cannot be committed cleanly

Preview results: Green means no issues. Yellow means there is a conflict to review. Red means the record cannot be committed and needs manual resolution. Do not commit an Update Set with red errors — investigate and resolve first.

Conflict resolution

When a conflict is found (same record modified in both instances), you choose which version wins:

  • Accept Remote — use the version from the Update Set (overwrite target)
  • Skip — keep the target version (ignore the Update Set version for this record)

The right choice depends on which version is correct. If you made changes in the Update Set that are newer and correct, accept remote. If someone made important changes directly in the target instance, skip and merge manually.

Merging Update Sets

When multiple Update Sets belong to the same release, merge them before moving to test. Select all Update Sets for the release, right-click, Merge. This creates a single Update Set that can be moved as one unit — cleaner than promoting multiple sets individually.

Common mistakes

  • Making changes in production directly — this creates drift that cannot be replicated or reversed cleanly. All changes must go through the dev → test → prod pipeline
  • Not setting a current Update Set — changes go into Default, impossible to isolate per release
  • Moving data via Update Sets — Update Sets are for configuration only. Move data via import sets or scripts
  • Not previewing before committing — commits with unreviewed conflicts can overwrite important production changes
  • One Update Set for the entire sprint — use separate Update Sets per feature or story so you can move or roll back individual items

Related guides:

Update Set best practices for teams

Update Sets are the ServiceNow mechanism for promoting configuration changes through environments — from development to test to production. Without disciplined Update Set management, organisations accumulate untested changes in production and have no reliable way to roll back or audit what changed. Establishing these habits prevents most common Update Set problems:

Update Set conflicts and resolution

Update Set conflicts occur when you try to preview or commit an Update Set on a target instance that has a different version of the same record (a Business Rule, Script Include, etc.). The conflict resolver shows you the incoming version (from the Update Set) and the current version (on the target instance) side by side. Common conflict causes:

Prevention is better than resolution: synchronise your development instance with production (via clone) regularly to minimise divergence, and communicate within the team when multiple developers are working in the same application area.

ATF — Automated Test Framework for Update Set validation

The Automated Test Framework (ATF) lets you run automated tests against configuration changes before promoting Update Sets. Building ATF test suites for your critical automations — key Business Rules, important Script Includes, Catalog Items — means you can validate that an incoming Update Set has not broken existing behaviour. ATF is the ServiceNow equivalent of unit and integration tests in traditional software development. For teams doing frequent releases, ATF is one of the highest-ROI investments in platform quality. See cloning instances for how to set up a testing environment for ATF validation.

Related: Cloning instances · Update Sets overview · Scoped applications · Instance Scan

For the topics covered in this guide, the most effective way to deepen your knowledge is hands-on practice on a Personal Developer Instance (PDI). ServiceNow provides free PDIs to all registered developers — request yours at developer.servicenow.com if you do not already have one. A PDI lets you experiment with configurations, break things safely, test edge cases, and build portfolio examples that you can demonstrate in interviews. Every senior ServiceNow practitioner has spent hundreds of hours on their PDI. It is the irreplaceable complement to reading guides like this one.

The weekly NowSpectrum newsletter delivers one focused, practical tip per week to your inbox — subscribe free at newsletter.nowspectrum.com. Each issue covers a specific pattern, common mistake, or practical technique relevant to working ServiceNow professionals. The archive covers every major platform area and makes for useful reference material when you encounter unfamiliar territory in a new project.

The Update Set workflow in practice

The daily workflow for development work in Update Sets: start your day by creating (or selecting) an Update Set for the change request you are working on, set it as your Current Update Set, and make your configuration changes. Every record you create or modify while an Update Set is current is automatically captured. When the change is complete, review the Update Set's customer updates list to verify everything you intended to capture is there — and nothing unintended has been captured. Mark the Update Set Complete, export as XML, and transfer to the test instance for preview and commit. Only after successful testing on the test instance should the Update Set be exported and committed to production. This workflow — develop, complete, test, promote — is the baseline that every ServiceNow team should follow regardless of scale.

The ServiceNow platform rewards practitioners who invest in deep, systematic knowledge rather than surface-level familiarity with every feature. The guides in this series are designed to build that depth — covering not just the API surface but the underlying mechanics, the common mistakes, the performance implications, and the architectural patterns that experienced developers and admins have learned through production work. Use this guide as a starting point and return to it as your experience deepens

Update Sets and the CAD/CSA exams

Update Sets are tested on both the CSA and CAD exams. The CSA tests the operational mechanics — complete, export, preview, commit, conflict resolution. The CAD tests the design decision — what belongs in an Update Set, what does not, and how to structure Update Sets for a multi-developer team working on a shared instance. Practice the full workflow on your PDI: create an Update Set, make changes, complete it, export the XML, load it to a second instance, preview it, commit it. Do this at least twice before sitting either exam.

Pass your ServiceNow interview

The NowSpectrum Interview Prep Kit covers 50 questions including Update Sets, CMDB, and platform administration topics.

Get the Interview Prep Kit →
← Back to all posts