How you correct a change depends on whether it ever ran.

Blocked before deployment

A change stopped by review or a policy check never ran, so its identity is still yours to change. Edit the changeset in place, rerun the checks locally, and resubmit through the same pipeline. Do not create a second changeset to patch a first one that never deployed.

Failed during deployment

A change that partially deployed has history. Do not edit a deployed changeset. Its checksum is recorded, and editing it causes checksum validation errors on the next run. See What is a changeset checksum?. Fix forward with a new changeset, or roll back and redo. The recovery paths are in Investigate a failed deployment and Decide whether to roll back or fix forward.

Resubmit through the same pipeline

Resubmission is a normal commit. Push the fix to your branch and let the same review and checks run again. Bypassing the pipeline to deploy the fix by hand recreates the problem governance exists to prevent.

Verify the resubmission

• The checks pass. The new checks run reports no violations at a blocking severity. Its Findings tabs show what was evaluated and what, if anything, still flags.

• The deployment succeeds. update exits 0 and the update summary shows your changeset in the Run bucket.

• The operation reports clean. The run appears in View database deployments, attributed to your changelog and connection, with a success status. A missing operation usually means an attribution problem. See Investigate an unattributed operation.

The full status signals are described in Understand deployment status.