ServiceNow Update Sets and Release Management: Guides and Services

What Update Sets Enable

Update sets capture configuration and code changes in ServiceNow so they can be transported between instances. A developer makes changes in a development instance, captures them in an update set, tests the changes, and then imports the update set into production. Update sets package changes so they can be moved between instances and give a record of what was captured and when.

Release management, meaning the process rather than any one product, coordinates multiple update sets into a cohesive deployment. A release might include update sets from multiple development teams, requiring sequencing to ensure dependencies are handled correctly and rollback is possible if problems occur. Update sets become the audit trail showing what changed and when.

Update Set Functionality

An update set records what changed: which tables were modified, what fields were added or changed, what workflows were created or updated, what business rules were added. When the update set is imported to another instance, it applies the same changes. Developers can manually edit update sets to include specific customisations or exclude unrelated changes that were made during development.

Update sets must be tested to ensure they work correctly in the target environment. Testing includes verifying that the changes work as designed, that they don’t break existing functionality, and that no data is lost or corrupted during import. Automated testing using Automated Test Framework can validate critical workflows quickly.

Version Control and Change Tracking

Update sets give a record of which customisations were captured and when. Each update set has a name and description, so the history of changes is documented. Before deploying an update set to production, the team reviews what changes it will make and approves the deployment.

Some organisations supplement ServiceNow update sets with Git version control for code, allowing more granular version history and code review processes. CI/CD tools can automate testing and deployment of update sets, reducing manual effort and improving consistency.

Rollback Planning and Procedures

A rollback procedure must be planned for each update set. For configuration changes, rollback might involve reverting the update set in the import tool. For data changes, rollback might require restoring a database backup. The team must verify that rollback procedures work before deploying to production.

If a deployment causes problems, rollback should be fast enough to minimise outage. This requires that rollback is tested and documented before deployment. Organisations should test rollback procedures during test environment deployments to ensure they work reliably.

Deployment Planning and Coordination

Release management coordinates multiple update sets into a scheduled deployment. The sequence of update sets must be planned so dependencies are handled: if one update set creates a table and another populates it, the first must import before the second. Release notes must be prepared documenting what changed and which systems are affected.

Deployment communication notifies affected teams before the deployment window and provides status updates during deployment. Communication includes the rollback plan so teams know what to expect if the deployment fails. Post-deployment verification confirms that changes applied successfully.

Oblytech’s Release Management Services

We help organisations establish release management processes that include update set planning, testing requirements, and deployment coordination. We implement continuous integration and continuous deployment pipelines using Flow Designer and Integration Hub. Implementation includes automation of repetitive deployment tasks and configuration of monitoring to catch deployment issues quickly.

CI/CD Pipeline Integration

Update sets can be integrated into continuous integration and continuous deployment pipelines. Automated testing runs against update sets before they are approved for deployment. Pipeline automation reduces manual effort and improves deployment reliability.

Deployment Tracking and Metrics

Organisations should track deployment metrics: frequency of deployments, mean time from approval to deployment, failure rate, and rollback rate. Metrics show whether release management is becoming more efficient and more reliable over time.

Choosing how changes move between instances

Before any release process is designed, the team has to decide how a change travels from the instance where it was built to the instance where it runs. The answer depends less on preference than on what is being changed, how many people change it at once, and what evidence the audit function will ask for later. Three approaches cover most situations, and mixing them without a rule is where confusion starts.

How a set moves from preview to commit

1. Create a named set in the source instance before any change is made. Changes made while the Default set is current are hard to separate later.
2. Make the changes, then mark the set complete so no further edits are captured into it.
3. Transfer the set to the target instance, and preview it there before committing anything.
4. Read every collision in the preview. A collision means the target holds a version of a record that differs from the one the set expects.
5. Resolve collisions by deciding, record by record, which version should survive, and note the decision in the set’s description.
6. Commit in the order the dependencies require, then run the verification steps for each changed area.
7. Keep the back-out path ready, and confirm it has been tested before the release window opens.

Naming and grouping rules that survive an audit

Every set should carry one purpose, a reference to the approved change, and a named owner. Sets that mix unrelated fixes make rollback unsafe, because reversing one fix reverses the other. Once a set is complete, it should not be edited. A new change gets a new set, even when it is a small correction, since an edited set no longer matches the evidence attached to it.

Grouping is easier to get right when the team agrees examples before the work starts. A single set might hold one table’s form layout and its related business rule, because they are changed together and tested together. A second set might hold a notification template that several teams share, and it deserves its own owner because a change there reaches every team at once. Writing two or three such examples into the release procedure gives developers a pattern to copy, which is more useful than a general instruction to keep sets focused.

Release windows and approvals

Windows exist to limit the damage from a failed promotion and to make sure people who support the platform are available if something goes wrong. The window should be set by the change calendar and the support rota, not by the date a developer finished the work. An approval should name the set, the target and the back-out owner, so the person signing off knows exactly what they are accepting.

What release management should measure

Track categories rather than targets that look precise. Useful groups are the number of promotions that failed in preview, the number that needed a back-out, the elapsed time between approval and production, and the share of changes that went through with complete evidence. A rising count of failed previews usually points to grouping or dependency problems earlier in the process, not to a fault in the tool itself. The governance model sets out who reviews these figures and how often.

Questions to settle with the change team

Can we use update sets and source control on the same application?

Mixing them on one application is hard to govern. Pick one authoritative path per application, and state it in the release procedure. Using both for the same artifact creates two histories that disagree, and the disagreement tends to surface during an incident.

Who is allowed to commit to production?

Limit production commits to a small group that is separate from the people who built the change. The commit is the moment the change becomes live, so it should carry the same approval that the change calendar requires, with the approver’s name recorded against the set.

What do we keep after a release is closed?

Keep the set, its preview output, the collision decisions and the approval together. Those items answer the questions that come up months later, and they are far easier to gather at the time than to reconstruct afterwards.

Does a lighter process apply to small fixes?

It can, provided the rules are written down. A small fix still needs a named set, a preview and an owner. What can be lighter is the number of approvers and the evidence sections, not the traceability itself.

Next step

The DevOps and release management guide and the update set explainer give a starting point for the comparison.

The release management practices worth enforcing in ServiceNow

The short answer to what good release management looks like on the platform: every change travels in a named, single-purpose package; every package is previewed and tested in an environment that matches production; and nothing reaches production without a back-out path that someone has already rehearsed. Most of the other advice in circulation is a refinement of those three habits.

It helps to read each practice as protection against a specific failure rather than as a rule for its own sake.

Update sets typically move configuration, not the records an application depends on, so any reference data a release needs should be listed and loaded as its own step. That is the single most common reason a release behaves differently in production from the way it behaved in testing.

Release management also sits inside a wider change process. How approvals, risk and scheduling are decided is covered under ServiceNow change enablement, and teams that want a defined operating model around it can look at change governance and release management. When a release is really a platform upgrade, the upgrades and release readiness guides cover the extra preparation that work needs.

Do small fixes need the full release process?

They need the same evidence, not the same ceremony. A single-purpose set, a preview and a recorded approver are enough for a low-risk fix, as long as the team has agreed in advance which changes count as low risk.

Update set tables, states and release management defaults to check on your instance

Release management in ServiceNow is the controlled movement of configuration from a development instance to production, and update sets are the usual carrier. The deciding fact is that a set only holds what was captured while it was the current set, so naming it, scoping it and completing it correctly matters more than the tool itself.

These are common out-of-box values. Check them on your own instance and release, because labels and defaults change between releases.

A set records customisations to records in tracked tables, so reference records and most data rows do not travel with it unless the team loads them on purpose. Release management on this page means the process, not a particular product. A team planning around a dedicated release-management application should confirm in its change plan that it is available on their release and instance.

Example (hypothetical): a team changes a form layout and a business rule on the incident table for one service desk. They name a set after the approved change, make both changes, mark it complete, retrieve it on test and preview it. The preview lists one collision on the business rule, because someone edited it in test. The team picks the version to keep, notes the decision in the set description and commits.

Teams using source control instead can start with DevOps on the platform. Application scope explains why a set’s scope matters, and change governance and release management covers approvals around the commit.

What is the difference between a local and a retrieved update set?

A local set is created on the instance you work in. A retrieved set is a copy brought in from another instance and is previewed before it is committed; the preview lists the problems it finds, such as a collision with a newer local version of a record.

Why did my change not land in the set I named?

The change went into whichever set was current when it was made, often Default for that application scope. Check the current set before editing, and keep its application aligned with the scope of the change.

Do update sets move data records?

Not by default. They capture configuration records in tracked tables. Reference records such as lookup values need their own load step, listed in the release plan beside the commit order.

Release management best practice in ServiceNow: a go or no-go gate before every promotion

The practice that does the most for a release is a go or no-go gate that every promotion passes before it reaches production. Proceed only when every collision in the target preview has a recorded decision, the back-out has been run on a non-production copy after the last edit, and a named approver has signed off the exact set being committed. If any one of those is missing, the answer is no-go and the set waits for the next window.

Four checks cover most of what goes wrong, and each one should give a yes or a no.

Small fixes pass the same four checks, usually much faster. What shrinks for a small change is the evidence: one preview result and one back-out run, not a folder of screenshots.

The most common failure is a gate that gets passed out of habit. The approver signs a set that was never previewed in the target, or the preview runs and its collisions are accepted without anyone writing down why. A useful test is to ask the approver to name the collision they were least sure about. If they cannot, the preview did not really happen. For collisions that do not make sense, the troubleshooting guide for update sets and release management is the next page to read. A back-out that exists only as a sentence in the change record is the second common failure.

When a collision cannot be resolved in time, the set should wait for the next window. Read the gate before the window opens, not during it. For a platform upgrade the same gate applies, with the acceptance checklist for upgrades as its evidence list. Where the gate has to be designed rather than just followed, the change governance and release management service covers the setup.