ServiceNow Update sets: Explained Step by Step

ServiceNow Update sets

Move configuration safely from dev to test to production.

Quick answer

ServiceNow update sets carry configuration between instances, forms, fields, business rules, client scripts, policies, flows and ACLs, anything under sys_metadata, and not data such as incidents, users or groups. Set the current update set in dev, mark it complete, retrieve it in the target, preview and resolve collisions, then commit. Scoped apps travel as application versions instead.

Key takeaways

What they capture, and what they don't
The promotion flow
Collisions and batching
Update sets vs scoped apps
Common mistakes

Update sets are how configuration travels between instances. They are the backbone of safe change management: build in dev, capture the changes, promote to test then production, never edit prod by hand. Understanding exactly what they do (and pointedly do not) capture prevents most deployment surprises.

What they capture, and what they don't

Captured (configuration)

Forms, fields, dictionary, business rules, client scripts, UI/data policies, workflows/flows, ACLs, anything extending sys_metadata.

NOT captured (data)

Incidents, users, groups, most records. Ordinary data needs an import or XML export/import.

Need reference data to travel too (e.g. a set of choice values or seed records)? Add them to the update set manually via Add to Update Set from the record's context menu, or move them separately as XML. Regular transactional data never belongs in an update set.

The promotion flow

Set your current update set in dev, every subsequent change is captured to it automatically.

Make your changes, then mark the set Complete.

In the target instance, retrieve the set (via an update source or XML import).

Preview it, resolve any collisions (a record changed in both instances) before committing.

Commit. If something is wrong, you can back out the set.

Collisions and batching

A collision means the target already has a different version of a record in the set, the preview flags it and you choose to accept or skip. Batching lets you group multiple update sets so they preview and commit together in dependency order, which is invaluable for larger releases.

Update sets vs scoped apps

Custom applications built in App Engine travel as application versions (or via the repo), not update sets. Update sets are for the Global scope. Don't try to drag a scoped app's changes into a global update set, capture the app version instead.

Common mistakes

Forgetting to set the current update set, so changes land in Default and can't be moved.
Expecting data to travel with the set.
Committing without previewing and walking into collisions on prod.
Committing update sets out of dependency order, so referenced records are missing.