Unify Logo Footer.svg
Platform Tools
Logo
Deploying and rolling back a change set

Deploying and rolling back a change set

Logo

4 min READ

Applying a change set to this environment, and undoing it if needed.

Overview

Clicking Deploy opens the Deploy Change Set dialog, where you pick the workspace the assets should be imported into and choose what to do with existing assets — Update Records (update assets that already exist here; the default) or Skip Records (leave them untouched). Deploying then applies the change set's assets to this environment — creating the New ones, updating (or skipping) the Existing ones, and mapping the Replaced ones. Before it changes anything, the platform backs up the current versions of the assets it's about to modify (so a rollback is possible), then applies the assets in dependency order — things that others depend on first (for example connections before the automations that use them) — so references resolve as each asset lands. As it goes it records a per-asset status (Deployed, Failed, Skipped). When it finishes, the change set is Deployed if everything succeeded, or Deployment Failed if any asset errored (which you can investigate via the error report).

Where: Inbound change set › Deploy

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

Group 9.png
Group 9.png

Rolling back a change set

One deployment nuance: when a change set deploys with standard deployment, agent skills are deployed automatically even though they don't appear in an agent's deploy tree (a skill attaches to agents by sharing, so it would otherwise arrive as a draft and the agent would run without it).

If a deployed change set causes problems, use Rollback Change Set on its inbound entry (available once the change set is Deployed — or Deployment Failed, so a partial deploy can be undone too). A confirmation dialog asks how you wish to roll back:

  • Only Unedited Records (the default) — reverts only assets that weren't changed after the change set deployed; anything someone has edited since is left alone.

  • Complete Rollback — reverts everything to the saved version from before the deployment, even assets edited afterwards.

The platform then restores the backup it took before deploying: assets that were newly created by the change set are removed, and assets that were updated are reverted to their pre-deploy versions. It does this in the reverse of the deploy order, so dependents come down before the things they depend on. The change set then shows as Rolled Back, and the source environment is notified so it sees the rollback too. Rollback is your safety net for a promotion that went wrong.

Where: Inbound change set › Rollback Change Set

FAQs

Why does deployment apply assets in a particular order?

Because assets depend on each other, the order matters: a connection has to exist before an automation that calls it, an object before an app bound to it, and so on. The platform sorts the assets by these dependencies and applies the foundational ones first, so that by the time a dependent asset is applied, everything it references is already in place. This is why you don't have to deploy connections separately and then automations — one deploy handles the whole bundle in the right sequence, which is also why a missing dependency shows up as a clear per-asset failure rather than a confusing partial state.

Where: Inbound change set › deploy (ordering)

What can't a rollback undo?

Rollback restores the snapshot taken at deploy time, so it has limits:

  • If you manually edited an asset after the change set deployed, a Complete Rollback overwrites those edits; choose Only Unedited Records to leave such assets alone (they're marked Skipped), so later work isn't lost.

  • If an asset was deleted in this environment after deployment, there's nothing left to revert.

  • Assets that were Replaced (mapped to an existing destination asset) or Skipped during the deploy weren't changed by it, so rollback leaves them as they are.

  • Rollback relies on the deploy-time backup; without it, a clean revert isn't possible.

So roll back promptly when a deployment is wrong, before further changes pile on top, and use Only Unedited Records when people have already worked on the affected assets.

Where: Inbound change set › Rollback (limitations)