An update set records configuration changes so they can be moved between instances, such as from development to production. Moving sets in the wrong order or editing the target manually causes conflicts that are tedious to untangle, so promotion discipline matters.
Before you start
You should be comfortable with instances and configuration records. This article covers update sets and conflict resolution.
Step by step
Step 1: Capture changes in a focused set
Keep one update set per feature or change so it can be reviewed and moved independently. A large catch-all set mixes unrelated changes and cannot be partially promoted or cleanly rolled back.
Step 2: Promote in dependency order
Move base sets before the sets that depend on them, because a dependent change expects the records the base set creates. Out-of-order promotion causes collisions where the target has an older or missing version.
Step 3: Resolve conflicts deliberately and avoid manual edits
A conflict is a collision between a set and the target’s current state. Resolve it by choosing the correct version with full context, not by keeping the default. Editing the target instance by hand creates untracked changes that the next promotion will not know about.
Worked scenario
The promotion preserves dependencies.
development: set A (new table), set B (business rule on that table)
promotion: apply A, then B
target edit: if someone hand-edited the table in prod, B conflicts
resolve: take the intended version, then re-record the target changeWalk through the example
Set A creates the table and set B depends on it, so applying A first avoids a conflict on B. A manual change in the target is the usual source of surprises, because it is not represented in any set. Resolving with context and capturing the manual change keeps future promotions clean.
Common mistake
Promoting a large catch-all set or moving sets out of order, so conflicts pile up. Another is making manual changes in a higher instance, which creates drift no update set records and causes unexplained conflicts later.
Verify the behavior
Preview the set and confirm the records it will change. Promote in order and confirm no unexpected conflicts. Compare the target with the set’s source to confirm the intended state, and check that no manual edits are left unrecorded.
Interview exercise
Why do manual changes in production cause update set conflicts?
Answer and reasoning
Because they are not captured in any update set, so the platform’s record of the current state differs from what the sets expect. When a set is promoted, the target has a version the set does not know about, producing a conflict or overwriting the manual change. Recording changes through sets keeps the source and target consistent.
Continue learning
Compare promotion in Scoped applications and validation in ATF behavior. Read the ServiceNow update sets documentation and try the ServiceNow interview questions.