A sandbox is a test environment with varying degrees of similarity to your production environment. You can use the sandbox to test, learn, and make mistakes without affecting your production environment. Zendesk has two types of sandbox environments: standard and premium. A standard sandbox reflects native Zendesk functionality with your basic settings, but not your data, whereas a premium sandbox replicates some of your data in addition to your basic settings.
Key facts about sandboxes
The types of sandbox available to you vary by plan:
- Support Enterprise includes one standard sandbox. Premium sandbox is available as an add-on.
- Suite Enterprise includes one standard sandbox and one partial premium sandbox.
- Suite Enterprise Plus includes one standard sandbox and one full production premium sandbox.
- You can only have one standard sandbox at a time. Plans with Premium Sandbox only have one premium sandbox as well, but more can be purchased as an add-on. Contact your sales representative or Zendesk Customer Support to purchase premium sandboxes as an add-on.
- The production instance owner is listed as the sandbox owner by default. This is true even if another admin creates or replaces the sandbox.
To provide a more realistic testing environment, all sandboxes take the following settings from your production instance of Zendesk Support:
- Templates (standard emails, welcome emails, etc.)
- Branding (colors, account names, etc.)
- Settings (channels, agent permissions, etc.)
If you're creating a premium sandbox, a lot of your production content is also replicated, including tickets and their associated end users. For more information about premium sandbox setup choices and data replication, see About premium sandboxes.
- In sandbox environments, closed tickets are automatically archived after three days.
- The activation status of the Zendesk Agent Workspace is replicated in all new sandbox environments.
- Some security settings aren't replicated in sandbox environments. However, if you're using two-factor authentication (2FA), that will continue to work in your sandbox, too, as long as the user has a password set in the production account.
- Sandboxes reflect a moment in time for your production account settings and data. Replicating settings and data isn't instantaneous and the data doesn't stay synchronized with production after the sandbox is created. If you need to configure additional syncing from production to your sandbox, you can do so using the REST API.
- We recommend deleting your old sandboxes and creating new ones regularly.
- Deleting a sandbox is a permanent change and can't be recovered.
- Changes you make in a sandbox don't affect your production environment.
- In most cases, if you're satisfied with the changes you tested in the sandbox, you can manually recreate them in your production environment. However, you can deploy automations (beta) and triggers from a premium sandbox directly to your production environment.
- You can start trials for other Zendesk products in your sandbox. Any trial
is subject to limitations and a fixed time limit, as specified when you sign
up for the trial. The trials are maintained as separate accounts and aren't
included as part of the sandbox.
- Sandboxes created after May 2023 include a Talk trial of an unlimited duration, as long as the production account has an active Talk subscription or trial. The sandbox Talk trial is suspended when the Talk credits run out.
- Sell isn't supported in sandbox environments.
Understanding standard sandboxes
- Help center content and customizations
- Zendesk Talk data
- Zendesk Chat data and customizations
- Security settings (except 2FA)
- API tokens
- Apps and integrations
- Conditional fields
- X (formerly Twitter) user identities
- Zendesk Support triggers, automations, macros, views, and custom fields
- Groups, organizations, and users
For more information about creating and using standard sandboxes, see Testing changes in your standard sandbox.
Understanding premium sandboxes
Premium sandboxes provide a test environment that closely mirrors your production instance in configuration and data. This enables you to more accurately test updates to workflows, experiment with integrations and new business rules, and train agents without affecting production.
For all types of premium sandboxes, the following content is replicated:
- Dynamic content
- Ticket fields
- Ticket forms
- User fields
- Organization fields
- Targets (set to inactive in the sandbox by default)
- Custom roles
- Shared views
- Shared macros
- Trigger categories
- Group memberships
- Webhooks (set to inactive in the sandbox by default)
For more information about how data replication works and limitations of the replicated data, see Understanding data replication in premium sandboxes.
Premium sandbox setup choices
- 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.
The types of premium sandboxes available to you depend on 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.
For more information about creating and using premium sandboxes, see Creating a premium sandbox with data replication.
Understanding data replication in premium sandboxes
Replication occurs automatically when you create a premium 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. For a complete list of the data that is replicated, see Understanding premium sandboxes.
The configuration of your sandbox instance will change rapidly while the replication is occurring, so we recommend waiting to use it until the replication completes. The time it takes for a replication to complete varies depending on the amount of content involved. A simple metadata copy with a small amount of fields and business rules takes 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 up to 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.
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 for a period of time, the sandbox and its data are deleted after the specified data retention period. The maximum number of replications you can perform per month for a sandbox, and how long sandboxes and their data are retained after you stop using them, depend on the sandbox type:
|Premium - metadata copy
|Premium - partial copy
|Premium - production copy
|Maximum number of replications per month
|Sandbox data retention
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, Talk or Guide.
- Brands are replicated, but because 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.
- Webhooks are replicated. However, all webhooks are deactivated in the Sandbox by default to prevent unintended interactions with the live APIs they're designed to connect to.
- 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 in production are deactivated within the sandbox upon creation but can be manually enabled.
- Side conversations are deactivated within the sandbox upon creation but can be manually enabled.
- 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.
- Invalid rules and objects that reference unsupported
configurations aren't replicated. Examples
- Conditions that reference ticket agreements
- Conditions that reference a deleted option or inactive field
- Unsupported conditions or conditions with dependencies that haven't been set up, such as a condition referencing custom objects or certain channels and integrations
- 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.
- 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. Personal views and macros aren't replicated.
- Only the first 100 comments are replicated per ticket.
- Skills used for skills-based routing aren't replicated.