Skip to content
IT Canvass
Menu
ServiceNow
SailPoint
SAP
TutorialsContact
Administration · Lesson

Update sets

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

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

1
Set your current update set in dev, every subsequent change is captured to it automatically.
2
Make your changes, then mark the set Complete.
3
In the target instance, retrieve the set (via an update source or XML import).
4
Preview it, resolve any collisions (a record changed in both instances) before committing.
5
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.

Want to learn this properly?

Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.

See the courseAsk a question

Check your understanding

  1. Update sets capture:

    • A. Configuration changes
    • B. Incident data
    • C. User passwords
    Show answer

    A. Configuration changes

    They capture configuration, not data records.

  2. To move data records between instances you use:

    • A. Update sets
    • B. Import sets
    • C. ACLs
    Show answer

    B. Import sets

    Import sets handle data; update sets handle config.

  3. You should select your current update set:

    • A. After building
    • B. Before you start building
    • C. Never
    Show answer

    B. Before you start building

    Set it first so your changes are captured.

Frequently asked questions

What does the term Update sets refer to in ServiceNow?

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.

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.
CallWhatsAppEnquire