Deploying a configuration from one environment to another

Moving tested changes into production, with a Test deploy first and a Revert afterwards. The snapshot you take is of the source, not of production.

Moving tested changes into production, with a Test deploy first and a Revert afterwards. The snapshot you take is of the source, not of production. You need to be an admin in both environments.

Deploy it

1. Save a snapshot of the environment holding the configuration you want to deploy.
2. In your production account, open Admin Center, click Account in the sidebar, then select Sandbox > Deployment and click Create deployment.
3. Give it a name, and name the source snapshot and the destination environment.
4. Select the configuration items to deploy, and read what the comparison says will change. Since 14 August 2026 that list also covers Agent Copilot (auto assist settings, procedures, communication guidelines, suggestions and writing tool settings) and Intelligent Triage (settings, topics and entities), so AI configuration can be tested in a sandbox rather than changed straight in production.
5. Click Test deploy to validate.
6. Click Deploy, then verify in production with a real ticket.

The snapshot goes on the source

A snapshot is a read-only copy of an environment's configuration at a moment in time, and the one you save at step one is of the environment you are deploying from. That is what the deployment reads.

Production is protected for you: when a deploy begins, Zendesk saves a snapshot of the destination before changing anything. Deployments that end up Deployed or Failed then have a Revert option in the management menu, which is your route back, and a Redeploy beside it for the case where you fixed the cause of a failure.

One thing to expect when you read the record afterwards: items that turned out to be identical in both environments are left out of it. So an item you selected and cannot find there was already the same, not skipped.

Test deploy is not a formality

Zendesk compares the selected configuration against the destination and surfaces the dependencies and conflicts that have to be resolved first. Anything in that list you do not recognise is a reason to stop, not a detail to accept.

Deploy deliberately, not everything

A sandbox accumulates experiments: half-built triggers, a field somebody was trying out. Select what belongs to this change and leave the rest.

Private apps cannot be deployed between environments at all, so anything depending on one needs its own plan.

Check trigger order afterwards

Triggers fire in list order, and a trigger sitting in a different position from the one you tested behaves differently. Look at the order in production once the deploy has finished, rather than assuming it matches.

Verify with a real ticket

Not by rereading the configuration. Send one that should match and one that should not, and watch what happens to each.

Do it when it is quiet: not before a peak, not at the end of the day, not on a Friday. If something is wrong you want time and a small queue. And announce anything agents will see before it appears, or a form that changes without warning generates tickets about your own change.

See also

• Managing configuration deployments
• Saving and managing configuration snapshots
• Comparing sandbox and production configurations