Update sets in ServiceNow Administration

Update sets

Move configuration safely from dev to test to production.

Quick answer

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.

Key takeaways

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

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.

Practice challenge

+0 XPStreak ×0

Question 1 of 3

Update sets capture:

Frequently asked questions

What does the term Update sets refer to in ServiceNow?

What is worth remembering about Update sets in practice?

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.

What is another point to note about Update sets?

Batching lets you group multiple update sets so they preview and commit together in dependency order, which is invaluable for larger releases.

What tends to go wrong with Update sets?

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.