Unify Logo Footer.svg
Platform Tools
Logo
Change set statuses

Change set statuses

Logo

4 mins READ

What each status means on the outbound and inbound sides, and per asset.

Overview

On the source environment, an outbound change set moves through:

  • Draft — you're still building/editing it.

  • Exporting — you've submitted it and the platform is snapshotting and packaging the assets.

  • Submitted — packaged and sent (or ready as a file); now read-only here.

  • Approved — a destination has approved it (reflected back from the destination).

  • Deployed — a destination has applied it.

And the terminal/problem states: Rejected (a destination rejected it), Rolled Back (a destination reverted it), Cancelled (you cancelled it), Failed (export/packaging failed), and Deployment Failed (a destination's deploy hit an error). Because one outbound change set can target several environments, you also see a per-destination status for each (covered under connected environments).

Where: Change Sets › Outbound, Status

Screenshot 2026-08-31 at 18.11.38 1.png
Screenshot 2026-08-31 at 18.11.38 1.png

Statuses

On the destination environment, an inbound change set moves through:

  • Draft — only for an inbound change set you're building yourself by pulling assets from a connected environment; you're still editing it. (Pushed and imported change sets never sit in Draft — they arrive as Pending.)

  • Pending — received/imported and awaiting review and approval(s).

  • Approved — all required approvals are in; ready to deploy.

  • Deployed — applied to this environment.

Plus: Rejected (an approver rejected it), Rolled Back (it was deployed then reverted), Cancelled (the sender deleted/withdrew the change set while it was still pending here), and Deployment Failed (one or more assets errored while applying). Reading the inbound status tells you exactly what's left to do: approve it, deploy it, or investigate a failure.

Where: Change Sets › Inbound, Status

FAQs

What do the per-asset statuses mean?

Within a change set, each individual asset also has its own status during import, so you can see exactly what happened to each one:

  • Deployed — successfully created or updated in the destination.

  • Failed — couldn't be applied (an error is recorded against it).

  • Replaced — mapped to an existing destination asset instead of being created (see review & conflicts).

  • Skipped — intentionally left untouched: it already existed and the deploy was set to skip existing assets, or a rollback skipped it because it had been modified since deployment.

  • Undeployed — not applied yet (including assets left out of the import selection).

  • Rolled Back — was deployed and then reverted.

This asset-by-asset breakdown is why a change set can be "mostly deployed" with a couple of failures you can drill into, rather than an all-or-nothing result.

Where: Change set details, per-asset status

Why is my change set "Deployment Failed" — what can I do?

Deployment Failed means applying the change set hit an error on one or more assets; the per-asset statuses and the downloadable Error Report show which assets failed and why (a missing dependency, a reference to something that doesn't exist in the destination, a permission issue). It isn't all-or-nothing — assets that succeeded are marked Deployed. From here you can roll back the change set (rollback stays available for a failed deployment) or leave the successful assets in place; then fix the underlying cause at the source (a missing dependency, an asset that needed mapping) and send or import a fresh change set.

Where: Inbound change set, error report