What are Update Sets in ServiceNow?

Context

Every ServiceNow environment has separate instances (dev, test, prod). Update Sets are how you package and move your changes between them. This is the deployment mechanism — and understanding it is essential for any role.

What Is an Update Set?

An Update Set is a container that automatically captures every configuration change you make while it's active. When you modify a Business Rule, create a UI Policy, or add a field to a table — that change is recorded in your current Update Set.

The Migration Process

// Step-by-step deployment:
//
// 1. SET your Update Set (Dev instance)
//    System Settings → Developer tab → Select 'My Feature Update Set'
//    Everything you change is now captured here
//
// 2. MAKE your changes
//    Create Business Rules, modify forms, add fields, etc.
//    Each change = one record in the Update Set
//
// 3. COMPLETE the Update Set
//    Mark it as 'Complete' — no more changes can be added
//
// 4. EXPORT from Dev
//    Right-click → Export to XML (or use Remote instance connection)
//
// 5. IMPORT to Test/Prod
//    Retrieved Update Sets → Import from XML
//
// 6. PREVIEW
//    System previews all changes and flags conflicts
//    'This Business Rule already exists — overwrite?'
//
// 7. COMMIT
//    Apply all changes to the target instance

What Update Sets Capture (and Don't)

• DO capture: Business Rules, Client Scripts, UI Policies, UI Actions, Script Includes, ACLs, form layouts, System Properties, Scheduled Jobs, Flow Designer flows, table schema changes (new fields/tables).
• DON'T capture: Data records (incidents, users, CMDB CIs), homepage/dashboard configurations (user-specific), report definitions (sometimes), attachment content.

Common Mistakes

• Wrong Update Set: Forgetting to switch your active Update Set before making changes. Your changes end up in the 'Default' Update Set and get mixed with other unrelated work. Always check your current Update Set before starting.
• Missing dependencies: You create a Script Include in one Update Set and a Business Rule that calls it in another. If you deploy the Business Rule first, it fails because the Script Include doesn't exist yet. Always track dependencies and deploy in order.
• Overwriting changes: Two developers modify the same Business Rule in different Update Sets. The second one committed overwrites the first — no merge, just overwrite. Communication is critical.