Update set strategy
Quick answer
Move changes between instances without collisions, missing records or last minute surprises.
Key takeaways
- Update sets capture configuration, not data
- Preview before commit, always
- Small, short lived sets prevent collisions
- Batches handle dependencies between sets
How update sets work
An update set captures configuration records as you change them. Data is not captured, and neither are records outside the tracked tables, which is the source of most failed deployments.
Avoiding collisions
Collisions happen when two people change the same record in different sets. Keep sets small and short lived, merge only when necessary, and always preview before commit so you can see what will be overwritten.
What update sets miss
Plan for the gaps.
- Data such as choices you created through an import, groups, users and catalog variables in some cases
- Scheduled job run times and system property values that differ per environment
- Anything created in a different scope or a different application
- Attachments to records, unless explicitly captured
A workable process
One set per change or story, named with the story reference. Complete the set when the work is done, promote through test, and never reopen a committed set. For larger releases use a batch so dependent sets commit in order.
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
What is not captured by an update set?
- A. Business rules
- B. Client scripts
- C. Data records
- D. UI policies
Show answer
C. Data records
Configuration is captured, data is not.
What handles dependent sets committing in order?
- A. A batch
- B. A merge
- C. A retro fit
- D. A clone
Show answer
A. A batch
Update set batches commit in dependency order.