- Suite Enterprise includes one partial premium sandbox instance.
- Suite Enterprise Plus includes one full production premium sandbox instance.
- Multiple premium sandbox instances may be purchased as add-ons to Support Enterprise plans.
With any of 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 set up choices
Premium sandboxes allow you to copy the configuration and tickets from your production environment. It also enables you to create and run more than one sandbox at a time
When creating a premium sandbox, you can choose from these setup options: metadata, partial, and production. 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 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 associated 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 then 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 is best to not use 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. A full copy with 100,000 tickets and their associated 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 and Help Center 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 which 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.