Update Sets capture your configuration changes so you can move customizations from development to production instances. This guide walks you through creating one and understanding what it does and doesn't capture.
The problem with manual change tracking
Before Update Sets, moving customizations between ServiceNow instances meant documenting every field you added, every business rule you wrote, and every form layout you changed — then manually recreating it all in production. Platform admins spent hours trying to remember what they'd changed, and inevitably something got missed. Developers had no reliable way to package their work, and production deployments were error-prone guessing games.
How Update Sets capture changes
An Update Set is ServiceNow's way of automatically recording metadata changes as you make them. When you set one as 'current', every field you create, every script you write, and every configuration you modify gets logged. Think of it as a change log that can be replayed on another instance. You create the Update Set, make it active, do your work, then export the captured changes for deployment elsewhere. The key insight: Update Sets only track metadata (configuration) — they completely ignore data records.
What Update Sets miss and why it matters
Update Sets have significant blind spots that catch people off-guard. They don't capture table data, uploaded attachments, some system properties, or changes made through certain admin interfaces. This means your test data, populated choice lists, and some security settings won't transfer with your customizations. Smart developers plan for this by scripting data loads separately and documenting the manual steps needed after Update Set deployment.
Before you start
- •admin role or personalize_update_sets role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to Update Sets
Go to System Update Sets > Local Update Sets. This shows all Update Sets created on your instance, including the 'Default' one that captures changes when no other Update Set is active.
Create the Update Set
Click 'New' to create a fresh Update Set. Fill in the Name field with something descriptive like 'Incident Form Enhancements' or 'Q2 Service Catalog Updates' — you'll thank yourself later when choosing what to deploy. The Description field is optional but useful for explaining what changes this contains.
Set it as current
Right-click the Update Set you just created and select 'Set as current' (or click into it and hit the 'Set as Current Update Set' button). The page refreshes and shows your Update Set as 'In progress' state. You'll see it listed in the banner at the top of every page.
Verify it's capturing changes
Make a small test change — add a field to a form, create a business rule, anything that modifies configuration. Go back to your Update Set record and check the 'Update Set Preview' related list. You should see your change captured as a Customer Update record.
If no changes appear, you're either modifying data (not configuration) or the Update Set isn't actually current.
Complete the Update Set
When you're done making changes, open the Update Set record and click 'Complete'. This locks it from further changes and makes it ready for export. The state changes from 'In progress' to 'Complete', and ServiceNow automatically creates a new 'Default' Update Set as current.
Export for deployment
From the completed Update Set, click 'Export to XML' to download a file you can import on other instances. The export includes all captured changes and their dependencies. Store this file somewhere your target instance can access it.
Best practices
Create focused Update Sets for specific features rather than catching months of random changes in one massive set — smaller sets are easier to troubleshoot when imports fail.
Always test your Update Set export on a sub-production instance before hitting production — imports can fail in unexpected ways and you want to debug on disposable data.
Don't leave Update Sets in 'In progress' state indefinitely — complete them when your feature is done so you're not accidentally capturing unrelated changes.
Remember that Update Sets won't transfer your test data, so plan to populate choice lists and reference data separately on target instances.
If you're modifying an existing customization, make sure the original changes exist on your target instance first — Update Sets don't include historical context.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue