CSA Guide

Update Sets: Best Practices for Clean Deployments

Introduction

Update Sets are ServiceNow's native change transport mechanism. They capture configuration changes—Business Rules, Client Scripts, UI Policies, ACLs, forms, and more—and package them for deployment from one instance to another.

Done well, Update Sets make deployments predictable and auditable. Done poorly, they become a source of merge conflicts, missing dependencies, and production incidents. This guide shows you the difference.

What Update Sets Capture (and What They Don't)

Captured Automatically

  • Script configurations (Business Rules, Client Scripts, Script Includes, etc.)
  • Form layouts and sections
  • UI Policies, UI Actions
  • ACLs, Roles
  • Workflows and Flow Designer flows
  • Service Catalog items and variables
  • Notifications, Email templates
  • Reports, Dashboards
  • System Properties (when explicitly added)

NOT Captured

  • Data records (incidents, users, CMDB CIs) — use Data Transfer Sets or import/export
  • Attachments on data records
  • System properties — unless you manually add them to the Update Set
  • Scheduled job execution logs

Update Set Naming Strategy

A consistent naming convention is critical in multi-developer environments:

Format: [Project/Story]-[Feature]-[Date]-[Developer Initials]

Examples:
  PROJ-1234-Incident-Priority-Automation-2024-03-15-JD
  HOTFIX-SLA-Breach-Notification-2024-03-20-SM
  SPRINT42-ServiceCatalog-NewHire-Workflow-2024-03-18-RK

Avoid vague names like "Updates March" or "John's Changes" — these become impossible to trace six months later.

The Developer Workflow

Step 1: Create a Dedicated Update Set Before You Start

System Update Sets > Local Update Sets > New

Set it as your current Update Set immediately. Never work in the Default Update Set.

Step 2: Work in One Update Set per Feature/Story

Mixing multiple stories in one Update Set creates dependencies that block individual deployments.

Step 3: Complete Before You Close

An Update Set should be Complete only when all related configuration is done and tested.

Step 4: Export for Cross-Instance Transfer

Update Set record > Export to XML

This generates a .xml file you can load into another instance.

Merging Update Sets

When multiple developers work on related features, you'll need to merge:

  1. Navigate to System Update Sets > Merge Update Sets
  2. Select the Update Sets to merge (order matters for conflict resolution)
  3. Review the merged Update Set before marking Complete

Best practice: Merge only in a designated integration environment, not directly in production.

Preview and Commit Process

Previewing

Always preview before committing:

Retrieved Update Set > Preview Update Set

Preview checks:

  • Customizations: Is this record already customized in the target?
  • Missing Records: Does this Update Set reference records that don't exist in the target?
  • Errors: Hard blockers that will prevent commit
  • Warnings: Soft issues worth reviewing (won't block commit)

Handling Preview Errors

Error Type Common Cause Resolution
Missing dependency Referenced record not in target Deploy dependent Update Set first
Customization conflict Same record changed in both source and target Accept remote or local based on review
Table not found Plugin not activated in target Activate the plugin first

Committing

After preview is clean:

Retrieved Update Set > Commit Update Set

This applies all changes to the target instance. The commit is not reversible without a backout plan.

Backout Strategy

Every deployment should have a documented backout plan:

  1. Before deployment: Export the current state of affected records from the target instance
  2. Create a "Rollback" Update Set: Manually capture the pre-deployment state of critical configurations
  3. Document the rollback steps in your change ticket

ServiceNow doesn't have a native "undo commit" — preparation is your safety net.

Multi-Developer Environment Tips

Avoid Stepping on Each Other

  • Assign ownership of tables/modules to developers
  • Use a shared tracking spreadsheet noting which developer owns which Update Set
  • Communicate before modifying shared configurations (form layouts, base Business Rules)

Source Control Integration (Washington DC+)

For teams using scoped apps, Git-based source control via Studio is strongly preferred over Update Sets. It provides:

  • Branching and merging at the code level
  • Pull request workflows
  • Conflict resolution with familiar tools
  • Full audit history

Best Practices Checklist

  • Never work in the Default Update Set
  • One Update Set per story/feature
  • Use consistent, descriptive naming conventions
  • Test in sub-prod before promoting to production
  • Preview and resolve all errors before committing
  • Document backout steps for every deployment
  • Merge related Update Sets before cross-instance deployment
  • Communicate with your team about shared configuration ownership
  • Manually add any System Properties you've changed
  • Archive exported XML files in version control

Conclusion

Update Sets are a powerful but unforgiving tool. The discipline you apply before you start coding—creating a dedicated Update Set, following naming conventions, planning your deployment—pays dividends every time you need to deploy cleanly. Pair Update Sets with a strong change management process, and your production instance will stay stable and auditable.

Keep reading this guide

Log in to access the full study guide and supercharge your preparation.