- Suite Enterprise includes one partial premium sandbox instance.
- Suite Enterprise Plus includes one full production premium sandbox instance.
Support Enterprise comes with a Standard Sandbox, but you can upgrade it with one or more premium sandboxes.
With these plans, you can also contact your sales representative or Zendesk Customer Support to purchase additional premium sandbox instances.
Premium Sandbox provides a test environment that mirrors your production instance of Zendesk Support or the help desk functionality in Zendesk Suite in configuration and, potentially, data. This allows you to accurately test updates to workflows, experiment with integrations, and provide training for new agents in an environment that closely mirrors the production environment.
This article contains the following topics:
Premium Sandbox setup choices
Premium sandboxes allow you to copy the configuration and tickets from your production environment.
Before creating a new sandbox, you must configure a default group for your account.
When creating a premium sandbox, you’ll be able to create set-up options according to your plan. For example, Suite Enterprise customers will be able to create a partial premium sandbox, and Suite Enterprise Plus customers will be able to create a full production sandbox. The content copied for all levels includes the following:
- Dynamic content
- Ticket fields
- Ticket forms
- User fields
- Organization field
- Custom roles
- Shared views
- Shared macros
- Agent level users
- Group memberships
When you create a metadata premium sandbox, no non-closed tickets or associated end users will be copied.
When you create a partial premium sandbox, up to 10,000 non-closed tickets and associated end users will be copied.
When you create a full production premium sandbox, up to 100,000 non-closed tickets and the related end users will be copied.
For more information about creating and managing premium sandboxes, see Managing Premium Sandboxes.
Replication occurs automatically when you create a sandbox through Admin Center. The replication retrieves data from the production instance and creates the configuration and content in the sandbox, creating a new subdomain. The process will not affect the performance of your production instance. Data is only retrieved from the production instance, so nothing will be added, updated, or deleted there. The configuration of your sandbox instance will change rapidly while the replication is occurring, so it's best to avoid using it during the process.
The time to complete a replication varies depending on the amount of content involved. A simple metadata copy with a small amount of fields and business rules can take less time, ranging from a few minutes to a few days. A full copy with 100,000 tickets and the related users and organizations can take a week or more to complete. When the replication is complete, the status of the sandbox changes to Active.
To complete the replication, Zendesk creates an internal copy of the data to be migrated. Once this migration is complete, this copy is deleted. A deleted Premium Sandbox is not recoverable.
Your choice of sandbox determines the maximum number of replications you can perform per month, as well as how long your sandbox and its data are persisted in the event you do not use your sandbox for a significant period of time. When you do not use your sandbox, the sandbox, and its data are deleted after a 30-day or a 90-day period of disuse.
This table describes the maximum number of replications you can perform per month for a sandbox, and how long sandboxes are retained:
|Premium - metadata copy||Premium - partial copy||Premium - production copy|
|Maximum number of replications per month||5||10||15|
|Sandbox data retention||30 days||90 days||90 days|
Limitations on replicated data
The replication will be as close of an exact copy of the production instance as possible. However, there are several situations where the copy cannot be exact:
- Sandbox test environments apply to Zendesk Support functionality in Zendesk Suite only and do not include, for example, Guide or Help Center content.
- Brands are replicated, but since brand names need to be unique across all Zendesk instances, they cannot be an exact match. The brand names will be modified to contain a unique string.
- User emails will be invalidated before being added to the sandbox instance by the use of the @example.com domain. This is to prevent emails from being inadvertently sent to your users. This includes both agents and end-users. An administrator can reverse the invalid emails for testing by editing the users' email addresses.
- APIs are enabled, but API tokens must be recreated.
- Apps and EAP functionality are disabled within the sandbox.
- Open tickets are migrated, but archived closed tickets, linked incident tickets, and ticket sharing agreements are not.
- Targets requiring a password will be replicated, but they will have invalid credentials and be in a disabled state.
- Any objects that are broken in production will not be replicated. For example, a trigger with a condition that refers to an organization that no longer exists will not be replicated to the sandbox.
- External email addresses are not copied to the sandbox.
- Changes made within a premium sandbox are not copied automatically into the production account and must be manually reproduced within the production account.
- Only the items identified in this article are replicated.
- Legacy agents can't be replicated. If you want them to be replicated, you must assign new roles to them.
- Views, triggers, and automations may appear in a different order in the sandbox.
- Inactive configurations are replicated, but business rules (for example, triggers and automations) that have conditions or actions which reference an inactive ticket field are not replicated.