Built something you're proud of? Tell the story. A quick G2 review of App Engine or Build Agent helps other developers see what's possible on ServiceNow. Share your experience.

ReleaseOps Pipeline Workaround: Fixing Failure When the Update Set Already Exists in Test

Umang Kedia2
Tera Contributor

9 hours ago

Introduction

I recently ran into an issue while using the ReleaseOps pipeline for update set promotion, and I wanted to share the workaround in case others hit the same blocker.

The problem happens when an update set has already been moved to the Test instance through Update Sources or another manual mechanism, and later you try to promote that same update set through the ReleaseOps pipeline. In that scenario, the pipeline can fail even though the update set itself is valid.

After testing the behavior, I found a simple workaround that allowed the deployment to proceed successfully.

The Problem

Consider a standard pipeline flow:

Dev → Test → Prod

If an update set already exists in the Test instance as a Retrieved Update Set, and you then try to push the same update set through ReleaseOps, the deployment fails.

This creates a problem for teams that may have initially moved an update set manually, but later want to bring that deployment back into the standard ReleaseOps process.

Root Cause

The ReleaseOps pipeline internally triggers a PullRemoteUpdateSetRequest from the Dev instance to the target Test instance.

If the retrieved update set already exists in the Test instance, the pipeline workflow does not populate the retrieved update set ID and instead returns null. As a result, the ReleaseOps flow moves into a failed state.

In short, the flow expects to retrieve the update set cleanly, but because a matching retrieved record is already present, the workflow cannot continue as expected.

The Workaround

The fix is straightforward: remove the existing Retrieved Update Set entry from the target instance before promoting the update set through ReleaseOps.

Steps

  1. Open the Test instance.
  2. Navigate to Retrieved Update Sets.
  3. Find the retrieved update set record for the update set you want to promote through the pipeline.
  4. Delete that retrieved entry.
  5. Go back to your Dev instance.
  6. Open the update set from Local Update Sets.
  7. Click the Promote Update Set UI action.
  8. Fill in the Deployment Request form.
  9. Move the request to the appropriate ready state in your ReleaseOps process.
  10. Start the deployment.

After this, the update set should move through the pipeline successfully to the Test environment.

Important Note

Once the update set is promoted and committed to Test through the ReleaseOps pipeline, you may notice two entries for that update set in the Local Update Sets table.

This is expected behavior.

Why? Because ReleaseOps retrieves and commits the update set again as part of its own deployment flow. So even though you deleted the earlier retrieved record to unblock the process, ReleaseOps creates its own entry during the promotion.

Why This Works

Deleting the existing Retrieved Update Set removes the conflict that prevents the PullRemoteUpdateSetRequest flow from resolving the retrieved update set correctly.

Once that duplicate retrieved record is gone, ReleaseOps can perform its retrieval logic normally and continue the deployment without falling into a failed state.

When This Is Useful

This workaround is especially helpful when:

  • an update set was already moved to Test manually,
  • a team later decides to use ReleaseOps for controlled promotion,
  • or a previously retrieved update set is blocking a clean pipeline deployment.

Recommendation

Before using this workaround in a shared environment, make sure you verify that the retrieved update set being deleted is only the duplicate retrieval record and not something actively being used by another process.

It is best to validate this approach in a lower environment first if your team has strict deployment controls.

Final Thoughts

If you are using ReleaseOps and your pipeline fails because the update set already exists in the target instance, check the Retrieved Update Sets table in the target environment first.

In my case, deleting the existing retrieved record in Test allowed the ReleaseOps promotion to complete successfully without further issues.

If others have seen the same behavior or found a different fix, I would be interested to hear how you handled it.

Labels:
  • 89 Views
0 REPLIES 0