Mastering System Update Sets in ServiceNow: A fun, practical guide for Admins 

If you’ve ever managed configuration changes across ServiceNow instances, you’ve likely navigated System Update Sets. They’re more than a tool—they’re a rite of passage for every seasoned Admin. Whether you're deploying enhancements, patching apps, or just trying not to break prod, update sets are your trusty sidekick. Let’s dive in—with a dash of fun and a heap of practical wisdom. 

Update Sets 101: What they are and why they matter 

At their core, update sets are containers for configuration changes—think of them as a suitcase you pack before traveling from dev, to test, to prod. They track changes to tables that extend sys_metadata, letting you bundle and migrate customizations like business rules, client scripts, UI policies, UI actions, ACLs, script includes, flows or workflows, and more. Treat update sets like source-control artifacts for your ServiceNow configuration. Organized sets equals predictable deployments! 

Under the hood, an update set is represented as XML and contains: 

• The records you changed (as update records)
• The configuration deltas
• Status and metadata for retrieval/preview/commit 

Update sets are ideal for:

• Storing and applying specific versions of applications
• Deploying patches and hot fixes
• Exporting configurations for backup, audit, or rollback planning 

What’s in vs. what’s out 

It’s helpful to remember what update sets do and do not capture. When you’re unsure, check whether the table extends sys_metadata or validate capture via a test change and preview. Captured examples include: 

• Business rules, client scripts, UI policies or actions 
• Script includes, ACLs, data policies  
• Dictionary entries, form or layout changes 
• sys_properties and app module menu configuration  
• Workflow Studio content scoped within your app 

Examples of what is not captured: 

• Data (e.g., Incidents, CMDB records, Tasks) 
• Users, Groups, or Roles (generally not metadata)  
• Attachments, images, and some binary assets  
• MID Server configs, external integrations’ runtime states  
• Some store-installed app content that’s managed by the App Repo or plugins 

Before you start: Configuration hygiene 

Good administrators don’t just “make it work”—they make it repeatable, auditable, and safe. Here are some tips to set yourself up for success:

• Naming conventions matter: Use short, meaningful names tied to requirements or tickets (e.g., STRY1001-IncidentFix). Avoid redundant info like dates or initials, as they may already be tracked.
• One scope per batch: Keep update sets scope-pure. Mixing scopes in a single delivery is a recipe for confusion and preview conflicts.
• Smaller, logical units: Favor smaller, purpose-built update sets over giant “kitchen sink” sets. They’re easier to test, review, and debug.
• Properties over backouts: Use system properties or feature toggles to disable a change quickly if needed—far safer than relying on backout.
• Don’t manually retarget updates: Never change the update_set field on records to “move” changes. Use platform mechanisms (e.g., retrieve, preview, commit, or the Merge Update Sets module) to maintain integrity. 

Creating and selecting Update Sets  

1. Create a new update set for each requirement or feature. 
2. Select it as the current set before making changes. Use the Update Set picker (Unified Navigation) to switch.  
3. In ServiceNow Studio, you can manage update sets in the Deployment tab or within the app context.  
4. Delegated developers can create/switch sets if permitted—helpful for team collaboration. 

Pro tip: Add a short description or link to the requirement in the update set record so approvers know what they’re looking at. 

Inspecting and reporting: Know what’s inside 

Understanding what’s inside your update sets is essential, as they function as more than just containers—they are fully navigable records. By opening an update set, you can easily browse all the updates it includes, drill down into individual records, and even view the differences between those and their current versions.  

To gain a clearer overview, you can quickly generate reports that review the contents by update type, such as all business rules that have been modified. Additionally, comparing your update set with the target instance helps you identify potential conflicts before deployment. It is always recommended to run an Instance Scan, which checks for risk patterns, violations of best practices, scope mismatches, and common anti-patterns. For critical branches or when update sets reach the “Complete” state, automating these scans can further enhance your deployment process. 

Packaging: Merge vs. batch  

You have two ways to group work: 

Merging: Use Merge Update Sets to combine records into a single set. Handy for consolidating several small sets into one deliverable—but introduces risk if overused or done late. 

Batching (preferred): Create a parent update set and insert scoped child update sets underneath. You deploy the batch as a coherent release while keeping each child logically independent. Batching by scope and feature makes deployments clearer and rollback/fix-forward decisions far easier. 

Moving Between Instances: Retrieve, Preview, Commit  

Retrieving batched update sets from remote instances is straightforward:

1. Export the update set (XML) from the source 
2. Import (use Retrieve) into the target instance. 
3. Preview to surface errors, missing dependencies, and collisions in the target instance.
4. Commit when clean (or after resolving conflicts), in the target instance. 

After committing in production, mark the update set as “Ignore.” This prevents the same set from being re-applied during a future retrieve (e.g., after cloning).  

Pro tip: Always preview before commit. Never skip it. The preview is your early warning system. 

Admin guardrails: Power with responsibility 

It’s important not to delete update sets, as doing so can orphan historical records and complicate future comparisons or audits. Avoid backing out the Default update set, since this set is unique to the system and modifying it can cause serious issues. Instead of manually editing update set references, always use the platform’s built-in merge, batch, and retrieve features to maintain integrity.  

Be careful not to mix scopes unintentionally; confirm both your current Application Scope and the active Update Set before making any changes to ensure accuracy. Finally, after committing update sets in production, set them to “Ignore” to prevent accidental reapplication during future clone or retrieve cycles. 

Conflict resolution: Compare local and remote 

Conflicts happen—especially in busy orgs. Make this comparison part of your pre-Complete checklist. Use compare tools to: 

• Preview local and remote sets and identify duplicate or competing records.
• Choose the right version to move forward (usually the newest or the one aligned with your target design).
• Resolve record-by-record where needed—particularly in scripts, UI policies, ACLs, and dictionary entries that multiple teams might touch. 

Best practices 

• Batch smart: Organize by scope, feature, and release using parent/child sets. Prefer batching over late-stage merges.
• Name wisely: Short, meaningful names tied to a ticket or feature (e.g., STRY1001-IncidentFix). Dates and initials are not recommended outside of a ServiceNow lab environment.
• Scan often: Run Instance Scan before “Complete,” after import, and before commit. Automate it where possible.
• Fix forward: Prefer feature toggles or system properties to disable problematic behavior rather than backing out changes.
• Keep sets small and cohesive: One logical change per set (or a small set of related changes). Easier to review, test, and promote.
• Don’t use "Default" for real work: The Default update set is only for capturing unintended drifts—never run projects from it.
• Mind the scope: Verify Application Scope and Current Update Set before you touch anything. This avoids accidental scope leakage.
• Preview every time: Resolve collisions and missing dependencies in preview; never commit without doing so!
• Document the why: A one-liner in the Description with a link to the requirement speeds code reviews and audits.
• Environment parity: Keep plugins, app versions, and properties aligned across dev, test, and prod to reduce preview noise.
• Security review: Changes to ACLs, script includes, or integrations deserve extra peer review.
• No manual field hacks: Don’t manually update_set fields, don’t delete sets, and don’t back out Default. 

Final thoughts: Update Sets with style 

System Update Sets may not be the flashiest tool in your ServiceNow arsenal, but they’re indispensable. Treat them with respect, and they’ll reward you with smooth deployments and fewer late-night rollbacks. 

So next time you’re prepping a release, remember: Batch smart, name wisely, scan often, and fix forward!

For information about update sets and other related Platform features, refer to the ServiceNow Product Documentation or visit the ServiceNow Community. 

Instructions to access the Delta exam

The following instructions will guide you through the process of completing your Delta exam: Completing your Delta exam