How to back up and restore your Zendesk configuration
Zendesk keeps no version history of triggers, automations, macros, views, fields and forms outside the Enterprise plan. This guide covers what to copy, the native options, the scripts many teams rely on and why they stop working in April 2027, and how to restore without breaking your queue.
What "configuration" means in Zendesk Support
Everything an admin builds in Admin Center that decides how tickets flow, and that a wrong click can undo in seconds:
- Business rules: triggers and their categories, automations, SLA policies, schedules with holidays.
- Agent tools: macros (with their categories and restrictions) and views (with columns, grouping and sorting).
- Data model: ticket fields and their dropdown options, ticket forms and their conditions, user and organization fields, custom ticket statuses, groups.
- Reusable text: dynamic content and its variants per language.
Tickets, users and organizations are data, not configuration; they have their own export tools. Apps, channels, Guide themes and Explore dashboards are configured elsewhere and are not covered here.
What Zendesk gives you natively
| Option | Plans | What it does | What it does not do |
|---|---|---|---|
| Trigger revisions | Enterprise | History of each trigger's changes with the author | Nothing for automations, macros, views, fields, forms; no bulk restore |
| Sandbox, snapshots and deployments | Enterprise (premium sandbox) | Copy configuration between a sandbox and production, compare snapshots | Not on Team, Growth or Professional; not a point-in-time backup of production |
| Audit log | Enterprise | Who changed what, when | Does not restore anything |
| Deactivate instead of delete | All | Inactive rules and fields keep their definition | Deleted objects are gone; deleting a field also deletes its values on tickets |
On Team, Growth and Professional there is no history and no undo. A deleted trigger has to be rebuilt from memory.
The script route, and the date that ends it
For years the standard answer has been a script: call GET /api/v2/triggers, /automations, /macros, /views, /ticket_fields, /ticket_forms, /slas/policies, /business_hours/schedules and /dynamic_content/items, save the JSON somewhere, and hope nobody needs to restore. Two problems:
- Authentication by API key ends. Zendesk announced the removal of API access by key: no new keys after 27 October 2026, unused keys switched off from 28 July 2026, every key off on 30 April 2027. Scripts must move to OAuth, which means registering a client and handling refresh flows, or they simply stop.
- Restoring is the hard part. A saved JSON contains ids of groups, fields, forms, statuses, schedules and webhooks. When the referenced object was deleted too, the rule cannot be recreated as it was; when a deleted object is recreated it gets a new id, and every rule that pointed at the old one has to be rewired. Views need their column list rebuilt as an "output" object, dynamic content variants are updated one by one, ticket field options are replaced as a whole (omit one and it is deleted). Few scripts handle any of this.
What a good backup does
- Takes a dated, hashed copy of every type above, with the read permissions of an admin, and keeps it where the team can reach it: inside the Zendesk account itself, in the browser, and as a file.
- Compares two copies, or a copy with the live account, and shows each changed value before and after in the words Zendesk uses.
- Restores with a simulation first, an automatic copy right before writing, dependency checks (create the group before the trigger that assigns to it, rewire ids), safe defaults (rules written inactive), and undo.
- Never deletes fields automatically, because that deletes ticket data; deactivates instead.
- Flags broken references (a trigger that assigns to a deleted group), unused rules, duplicates and views that show inactive fields, so the configuration gets cleaner over time instead of only bigger.
How often, and when
A copy before every change session in Admin Center, and at least weekly. Before onboarding a new admin, before a migration or a merger of accounts, before the annual clean-up, and right before you deactivate anything that other rules may depend on. Keep the copies for a year; the cost is a few megabytes.
Restoring without breaking the queue
- Compare the copy with the live account and read the list of changes; restore only what you recognise.
- Run the simulation and read every warning. A missing group or field means the rule will be skipped or created pointing nowhere; create the dependency first.
- Restore triggers and automations inactive, check them in Admin Center, then activate them one by one. A trigger activated with the wrong condition can e-mail every requester in minutes.
- Keep the pre-restore copy until you are sure; that copy is your undo.
Apps that do this inside Zendesk
Config Guardian, from the developer of this site, runs inside Zendesk Support with no server: snapshots of the fourteen types above, comparison, restore with simulation, pre-restore copy, dependency rewiring, safe mode and undo, health checks, and copies stored inside your own account as a custom object. Free for snapshots and comparison; Pro at $69 per account per month adds restore and account storage; Business at $149 adds restore from another account (sandbox to production), evidence records and a printable change report.
Other options, from public documentation in September 2026: configuration platforms such as Salto and Keepit keep copies on their own servers with a per-company subscription; single-purpose Marketplace apps show configuration dependencies or list broken rules without restoring; the Enterprise plan bundles sandbox deployments and the audit log. Check their pages before deciding; details change.
Frequently asked questions
Does restoring a trigger run it on old tickets? No. Triggers act on ticket events after they are saved; updating or creating one does not touch existing tickets.
Can I copy the configuration from my sandbox to production? With Enterprise, through deployments. Without it, a snapshot taken on the sandbox can be restored on production by an app that matches objects by title and lists what could not be matched; Config Guardian does this on its Business plan.
Is a JSON export enough for an auditor? An auditor wants a dated copy, its hash and proof that it was not altered. Export a ZIP with a manifest of hashes, or keep the copy inside the account where it cannot be edited by hand.
What about Guide? Articles, sections and categories are content; Help Center Doctor keeps snapshots before bulk changes and offers undo there.
Support: support@helpcenterdoctor.app.