Common ServiceNow Update Sets and Release Management Mistakes and How to Avoid Them

This page covers the mistakes that cause failed ServiceNow update set releases, with the symptom, root cause, fix and prevention for each. Update sets carry configuration changes between environments, and release management coordinates the move to production. Mistakes in testing, dependencies, rollback, documentation, authorization, communication and timing cause failed deployments or outages.

Update sets and release management challenges

Update Sets carry configuration changes through environments. Release Management coordinates deployment to production. Mistakes in this process cause failed deployments, data loss, or production outages.

Mistake 1: Inadequate update set testing

An update set is deployed to test environment but not tested thoroughly before moving to production. Issues discovered only in production.

Symptom: production deployment fails or breaks existing functionality. Rollback is needed.

Root cause: testing in test environment was incomplete. Or test environment is different from production (different data, different configuration, different integrations).

Fix: ensure test environment mirrors production (same version, same customizations, same data). Run comprehensive tests in test environment before production promotion. Include regression testing (did we break anything).

Prevention: define and enforce test requirements before any production promotion. Do not skip testing to save time.

Mistake 2: Update sets with conflicts or dependencies

Multiple update sets are being worked on in parallel. When they are promoted together, they conflict (same field modified in different update sets) or have dependencies (update set A depends on update set B).

Symptom: deployment fails due to conflicts, or one update set fails leaving the other incomplete, or A fails because B was not promoted first.

Root cause: developers did not coordinate work. Or dependencies were not identified.

Fix: identify all update sets in the current release and map dependencies. Promote in dependency order (if A depends on B, promote B first). Check for conflicts before deployment. Use version control to track update set relationships.

Prevention: enforce a release planning process. Before developers start work, the release plan identifies who is working on what and what the dependencies are.

Mistake 3: No rollback plan

An update set is deployed to production. Issues occur. The team does not know how to rollback, or rollback is slow and causes extended outage.

Symptom: production issues continue because rollback is not possible or is manually complex.

Root cause: no rollback plan was documented or tested.

Fix: before deploying, document the rollback procedure: how to revert the update set to the previous version, whether that requires database restore, how long it takes, who needs to be notified. Test the rollback before any production deployment (test in test environment).

Prevention: rollback plan is a release requirement. No deployment happens without it.

Mistake 4: Poor update set documentation

An update set is deployed but documentation is missing: what changed, why it changed, what testing was done. Future support staff do not understand what the update set does.

Symptom: when a bug is found in code that was in the update set, investigating why the code is there takes time. Changes are fragile because no one understands the reasoning.

Root cause: developers thought documentation was not necessary or was deprioritized.

Fix: update set documentation is mandatory: what is being changed (summary), why (business justification), what is the impact, testing completed. Document in the update set itself or in linked release notes.

Prevention: update set documentation is part of definition of done. Code review includes checking documentation.

Mistake 5: No change management or authorization

Developers deploy update sets to production without going through change management process. No approvals, no notification to stakeholders. Change authority does not know what was deployed.

Symptom: unauthorized changes reach production. If issues occur, leadership was not informed. Audit finds unauthorized changes (compliance violation).

Root cause: no governance around deployment, or governance is bypassable.

Fix: establish release management process. All production deployments require approval from a release manager or change committee. Approval is only granted after testing is confirmed, risks are assessed, and rollback is planned. Use workflow to enforce the process (system does not allow promotion without approval).

Prevention: release governance is a control, not optional.

Mistake 6: Inadequate communication about deployments

An update set is deployed to production. Users and support team are not notified. They encounter unexpected behavior and do not know why. Support is flooded with calls.

Symptom: support load spikes after deployment. Users complain about unexpected behavior. Issues are misdiagnosed because people do not know what changed.

Root cause: release communication was not planned or was inadequate.

Fix: communication plan for every release: who needs to be notified (users, support, management), how (email, Slack, meeting), what information (what changed, how it affects users, where to get help). Communicate before deployment (heads up), during deployment (status), and after (confirmation). Know who the important stakeholders are and communicate directly with them.

Prevention: release communication is a documented step in the deployment process.

Mistake 7: Deployment during high-risk times

An update set is deployed to production on Friday afternoon or during end-of-month close when support team is busy. Issues occur and no one is available to respond.

Symptom: deployment issues are unresolved for hours or days. Business is impacted.

Root cause: deployment timing was not considered. Or deployment was urgent and scheduled for the next available time (which happened to be high-risk).

Fix: deploy during designated deployment windows when support is available and business impact is lowest. Typically mid-day mid-week. Avoid end-of-month, end-of-quarter, or known busy periods. For emergency deployments, ensure resources are available to respond.

Prevention: deployment scheduling is a release requirement.

Mistake 8: Lost update sets or missing change history

An update set was deleted, overwritten, or lost. The organization does not know what was changed in a previous production deployment. Can’t reproduce the issue or rollback cleanly.

Symptom: inability to maintain the production system, changes seem to get lost, rollback is not clean.

Root cause: update sets are not backed up or version-controlled. They live only in the development instance.

Fix: store update sets in version control (Git) immediately after promotion to production. Keep a record of every production deployment (what was deployed, when, what testing was done). Archive old update sets.

Prevention: update set version control is a required process step.

Working in the Default update set

One trap sits underneath many of the mistakes above. When no named set is selected, changes are captured into the Default set, and that set collects the changes a developer makes in that scope until they switch to a named set.. A developer fixing an unrelated problem can therefore carry the fix into a release they never meant to include. The signs are a Default set with many unrelated entries and a release that contains records nobody can explain. The correction is to create a named set before the first change, and to review the contents of Default before any promotion, moving each entry into the set it belongs to.

Pre-deployment red flags

Recovery sequence when a bad set is already in production

1. Freeze further promotions to the affected application until the cause is known.
2. Identify the set, its commit time and every record it changed, using the commit log rather than memory.
3. Decide whether to back out the whole set or to correct the defect forward. Forward correction is often safer when the set touched several records that other changes now depend on.
4. If backing out, run the back-out in a lower environment first, and check that the reverse set restores the previous state.
5. Record the decision, the owner and the times in the incident record before the change is made.

Keeping evidence after recovery

Recovery work tends to be fast and under pressure, which is exactly when evidence goes missing. Keep the original set, the preview output, the commit log, and the notes on each decision together. Those records explain what happened to the people who weren’t in the room, and they show whether the same grouping error is likely to recur on the next release. The update sets and release management overview and the testing and acceptance checklist are the platform-side references for this evidence.

Questions about update set mistakes

Is it safe to delete the Default set’s contents?

Not without review. Entries in Default may be needed by someone else’s work, and deleting them removes the only record of what changed. Move each entry into the correct named set instead, and only then clear what is left.

How do we stop developers from making direct production edits?

Restrict production edit rights to a small group and make sure the emergency path still leaves a record. A process that forbids direct edits but has no emergency route will be bypassed quietly, which is worse than a documented exception.

Should a preview with no collisions be trusted without reading it?

No. An empty collision list means the system found no direct conflicts. It does not show whether the change is correct or whether it depends on something the target lacks. Read the set contents as well as the preview output.

Next step

The change freeze governance article covers how freezes are governed, including exceptions.