ServiceNow Update Sets and Release Management Best Practices

Bundling Changes into Update Sets

An update set is a collection of configuration changes that are deployed together. The first best practice is thoughtful bundling: group related changes into a single update set, not one change per update set.

What good looks like: an update set titled “Incident Management: SLA Configuration and Notification Updates” contains a related set of changes (new SLA table, SLA rules, and email notification templates). All changes are logically connected and should be deployed together.

What to avoid: deploying hundreds of unrelated small update sets or bundling unrelated changes together. Too many update sets is hard to track; bundling unrelated changes makes it hard to roll back specific features if issues arise.

Version Control and Change Documentation

Every update set should have clear versioning and documentation. Use version names such as release labels, or a dated label that carries the release date. For each update set, document: what changes are included (list of tables/objects modified), what problem the changes solve or what feature they enable, what dependencies exist (must this update set be deployed after another one), who approved the update set, and test results.

What good looks like: an update set documented with a clear title, description of all included changes, pre-deployment checklist (dependencies to verify), and post-deployment validation steps.

What to avoid: undocumented or poorly-named update sets (“changes from Friday”), incomplete change descriptions, or unclear version numbers.

Testing Update Sets Before Deployment

Never deploy an update set to production without testing it first. Test in a staging or pre-prod environment that is as close to production as possible. Follow these steps: (1) Import the update set, (2) execute any included tests or validation scripts, (3) manually test the new functionality, (4) verify that existing functionality still works, (5) confirm performance is acceptable, (6) verify security (access controls are correct, sensitive data is protected).

Document test results. If the update set passes testing, sign off. If issues are found, document them, fix the update set, re-test, and re-sign-off. Do not deploy if testing is incomplete.

Deployment Process and Sequencing

Establish a consistent deployment process. Who can deploy update sets? Usually, release managers or designated deployment personnel. When can deployments happen? Usually outside of business hours to minimize user impact. Do deployments require approval from a change advisory board? For critical systems, yes. For low-risk changes, approval may be lighter.

Sequencing matters if update sets have dependencies. If Update Set B depends on Update Set A, deploy A first, verify it is working, then deploy B. Do not deploy dependent update sets simultaneously; if A fails, B may fail too.

Rollback Planning and Execution

Before deploying any update set, have a rollback plan. What is the procedure if the update set breaks critical functionality? For most update sets, rollback is a back out: run the Back Out action on the committed set, which reverses its changes, and check the result. For update sets that include data changes (existing records modified), rollback may be more complex; you may need to restore data from backup.

Test the rollback process in staging before you ever need to do it in production. Know how long rollback will take and who has authority to execute it.

Release Notes and Communication

After deploying an update set, communicate what changed. Release notes should describe new features, changes to existing features, resolved issues, and any actions required from users. Provide release notes to stakeholders before deployment so they know what to expect.

What good looks like: clear, concise release notes that end users can understand. Avoid jargon. Highlight new features and how to use them. Explain changes to existing functionality so users know what to expect.

What to avoid: overly technical release notes that only developers understand, or release notes so brief they do not provide useful information.

Update Set Security and Code Review

Before deploying an update set to production, have a second engineer review the contents. Code review catches errors, identifies security issues, and ensures changes follow standards. Documentation should be reviewed for clarity. A brief code review sized to the update set before deployment prevents many production issues.

Production Promotion Checklist

Before promoting an update set to production, verify: all dependencies are met, testing results are documented, rollback plan is ready, backup is taken, stakeholders are notified, and approval is signed. A checklist prevents the common mistake of deploying too quickly. Allow a buffer between final approval and actual deployment; this buffer allows last-minute issues to be identified.

Deciding whether a change belongs in one set or several

Teams that already have a naming convention still struggle with the question of boundaries: when do two edits belong in the same set, and when does splitting them make the release safer? The answer depends less on how big the change is and more on whether the parts can be accepted or rejected independently. A new approval rule and the notification that announces it can usually travel together. A reporting change and an unrelated access change should not, even if both were built on the same afternoon. Make the boundary decision before the developer starts recording, because regrouping sets after the fact means copying changes between sets, which is where errors creep in.

A pre-commit review sequence for update sets

Before a set leaves the development instance, the reviewer should be able to answer each of the following from the record alone, without asking the developer:

1. Is the set in a complete state, and has its contents stopped changing? A set that is still receiving edits cannot be reviewed.
2. Does the description state the purpose, the tables and areas touched, and the reason the change exists, with a link to the request that asked for it?
3. Does the content list match the description? Surprise records, such as a test field or a debug script left in place, are a common reason a set fails review.
4. Is there a previewed collision report on the target, and does every entry have a recorded decision?
5. Is the back out plan written down, including whether the change is reversible by removing the set or needs a data restore?

Handling collisions and changes made after a set is complete

A completed set should be treated as frozen. When a fix is needed after completion, create a new set that corrects the earlier one rather than reopening it and editing records. Reopened sets lose their meaning: the copy a reviewer approved no longer matches what gets promoted. For collisions, record who decided each one and why. Decisions taken at that stage deserve the same scrutiny as a change risk assessment, because an accepted collision changes what the release actually does.

Hotfix sets and the discipline that keeps them safe

Urgent fixes need their own path, not a shortcut around the review. Keep the hotfix set small, name it for the defect it addresses, and make the same review steps happen, perhaps faster, with the reviewer present at the time of promotion. Once the hotfix is in production, bring the same change back into the development line so the next normal release does not reintroduce the defect. Teams that skip this step often find the defect returning after an unrelated release, and the second investigation is usually harder than the first.

Frequently asked questions about update set practice

Can a developer reuse an existing set name for a new piece of work?

It is better not to. Reused names make the audit trail ambiguous, because the same label then refers to two different sets of changes. Start a new set with a name that describes the new purpose and point the description at the earlier work.

What should happen when the target instance contains changes the set does not know about?

Stop and find out why before promoting. Unknown changes on the target usually mean someone made a direct edit outside the release process. The collision preview is the place to see them, and the decision to overwrite, keep or merge should go to the owner of the affected area.

Is it acceptable to combine two small unrelated fixes to save a review cycle?

Usually not. The saving is small, and the cost appears when one fix has to be backed out because of the other. If the review load is the real problem, reduce the number of sets being raised rather than merging unrelated work to reach a lower count.

Next step for tightening your update set standard

The DevOps and release management guide covers the wider delivery process around these reviews.