Plan requirement
| Subscription | Suite Growth or higher, Support Professional or higher |
| Access | Admin |
A sandbox is a separate copy of your configuration where a mistake costs nothing. Triggers, fields, forms and views can be built and broken there without anybody noticing.
Why it matters here specifically
Zendesk has no draft state. Saving a trigger means it fires on the next ticket, and a badly scoped one can touch every ticket in the queue within minutes. A sandbox is the draft state the product does not give you.
| Plan | Sandboxes |
| Support Enterprise | One included |
| Suite Enterprise and Enterprise Plus | Two included |
| Support Professional and above, Suite Growth and above | Available to purchase |
How much real data goes in
More than a blank copy. When you create a sandbox you choose how much ticket data to replicate: 0, 500, 5,000 or 10,000 tickets. An equal number of tickets that are not closed and have been updated in the last six months can be replicated as well.
You can run at most 10 replications per month, so a sandbox is something you refresh deliberately rather than every morning.
Because real tickets can be in there, a sandbox is not a place where data protection stops applying. Who has access to it deserves the same thought as your production account.
What belongs in one
- New triggers and automations, above all anything that sends email.
- Changes to forms and fields, which agents see immediately.
- Routing changes, where the effect only shows under real volume.
- Anything you would rather not have to explain at ten on a Monday.
What it is not
It is not a backup: it does not protect your live data, and nothing you do there is a safeguard against losing something in production.
Nor is it a complete copy of your channels. Text, for one, does not work in a sandbox at all, so anything that depends on sending a message has to be tried on the live account. Worth checking per channel before you plan a test around one.
Comments
0 comments
Article is closed for comments.