Zendesk Support Enterprise includes a sandbox instance where you can test changes, experiment with integrations, and provide training for your agents. However the standard sandbox does not provide a replica of your production instance. It starts as a nearly empty instance with only a few things copied over from your production instance, including administrator level users, email templates, branding, and basic settings.
If you, as a Zendesk administrator want to test a change to a workflow, you must manually copy over all of your current ticket fields, forms, user and organization fields, triggers, automations, and so on. Additionally, if you want to test against ticket data, you must recreate the tickets in the sandbox, which can be time consuming and prone to error.
The Zendesk Premium Sandbox mirrors a production instance in configuration and, potentially data. This allows you to:
This article contains the following topics:
What is Premium Sandbox?
Premium Sandbox is an add-on you can purchase for your existing Support Enterprise sandbox. The add-on gives you access to a process that will copy content from the production instance to the sandbox instance.
There are three levels of Premium Sandbox that you can choose from: metadata, partial, and production. The content copied for all levels includes the following:
- Brands
- Dynamic content
- Ticket fields
- Ticket forms
- User fields
- Organization field
- Targets
- Groups
- Custom roles
- Views
- Macros
- Triggers
- Automations
- Agent level users
- Group memberships
If you purchase the partial or full version of Premium Sandbox, the following objects can be copied:
- Users
- Organizations
- Tickets
Comparing the sandbox levels
This table describes the different sandbox levels:
| Enterprise | Premium - metadata copy | Premium - partial copy | Premium - production copy | |
|---|---|---|---|---|
| Templates and branding | Y | Y | Y | Y |
| Settings | Y | Y | Y | Y |
| Customer lists | Y | Y | Y | Y |
| Add-ons | Y | Y | Y | Y |
| Roles and groups | Y | Y | Y | |
| Business rules: triggers and automations | Y | Y | Y | |
| Views & macros | Y | Y | Y | |
| Ticket forms | Y | Y | Y | |
| Custom fields: ticket, org, user | Y | Y | Y | |
| Tickets, end-users, orgs, data | Up to 10,000 tickets | Up to 100,000 tickets |
If you are interested in adding the Premium Sandbox to your Zendesk account, contact your account executive.
Requesting a Premium Sandbox replication
The replication process is not automatic. Instead, the replication is performed at a scheduled time by the Zendesk Platform Services team. The replication is a series of API calls to retrieve data from the production instance and another series of API calls to create configuration and content in the sandbox.
Before you submit the ticket, you must reset the Sandbox to ensure that the environment is clean and ready for the replication. Make sure you understand the effects of resetting your sandbox, and check with any development or change management teams before performing the reset.
To start the replication, submit a ticket on the Zendesk Help Center. The ticket should use the Paid Professional Services topic with a Professional Services Needed option of Licensed Sandbox Refresh.
When you are ready to submit the ticket, include in the ticket the subdomains of both the production and sandbox instances. Also include the preferred date of the replication. Once you submit the ticket, the Platform Services (PS) team will review the ticket, reply with any follow-up questions, and coordinate on the time. They will need the following from you:
- Enable Account Assumption in the production instance
- An API token for your production instance
- An admin level user to run the API calls in the production instance
- An API token for your sandbox instance
- An admin level user to run the API calls in the sandbox instance
Do not send API tokens within the ticket. In the ticket, the PS team will request to create API tokens in the two instances. If you agree, the tokens will be created just before the replication begins and then deleted as soon as the replication is completed. If you'd prefer to create the tokens yourself, the PS team will coordinate the delivery method within the ticket.
Once the Platform Services team has the necessary information, they will begin the replication. This involves a number of API calls to retrieve and create data in both systems. 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 as little as an hour. A full copy with 100,000 tickets and their associated users and organizations can take a day or more to complete. The Platform services team will update the ticket to let you know when the replication is complete. The following table describes how often you can replicate, and how long the process takes:
| Sandbox type | Metadata copy | Partial copy | Production copy |
|---|---|---|---|
| Minimum replication request interval | 5 days | 5 days | 30 days |
| Initiation of sandbox replication | Up to 3 business days | Up to 3 business days | Up to 3 business days |
| Completion of sandbox | Up to 2 days | Dependent on data volume | Dependent on data volume |
Replication caveats
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:
- 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. This is to prevent emails from being inadvertently sent to your users. This includes both agents and end-users
- System generated targets and targets requiring a password will not be replicated
- 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
- Sharing agreements are not replicated
The replication of the configuration objects and data is not instantaneous and it is not an ongoing replication. In other words, it is a point in time copy from when the replication process starts. If changes are made in production after the replication completes, those changes will not be reflected in the sandbox.
When you reset your sandbox, you need to be aware of the following:
- The sandbox URL will change every time you reset
- All object IDs in the sandbox will change, for example, ticket field IDs will be different every time you reset
- Any custom Guide themes will be lost, though they can be exported prior to the reset
- All apps will be removed
- Any sharing agreements will be removed
Remember to coordinate with your internal development teams before you reset your sandbox. If they have an integration with your sandbox, they will likely be making reference to the unique object IDs in the sandbox. You won’t want to surprise them with a reset and break all of their integrations.
Next steps
Once the replication is complete, the Platform Services team will again coordinate with you on the ticket to resolve any questions you might have. When they close the ticket, they will also remove any API tokens that were created for the process.
With your newly replicated sandbox, you will have an environment that closely mirrors your production instance. This enables you to test out new workflows, give your agents a safe place to train, and provide a high-quality environment for development purposes.
If you are interested in adding the Premium Sandbox to your Zendesk account, contact your account executive.
5 Comments
Wondering why this is a separate product, and not just the "standard". Surely, everyone wants to test against a true representation of their instance?
Hi Chris,
Sandbox users do have the ability to test with settings similar to their Production site, however, unless you have the add-on you would need to manually configure this through the agent interface or the Rest API.
There are some cases where customers will use their Sandbox account to test account features without affecting their Production site. Therefore duplicating account settings may not be necessary in that scenario.
I understand the need for having this process automated but unfortunately this is only available with the Premium Sandbox add-on. If you're interested in having this feature available on the standard sandbox I would encourage you add your feedback to our Support Product Feedback forum for our Product Managers to review.
Appreciate you taking the time to share this with us!
This add-on feels more like it should be a standard feature or included at least on top tiers. Does these sandbox options allow to move instance from sandbox to production?
In todays world, ALL major providers provide a sandbox comprehensively, how you guys have not done this yet is beyond me.
We are having to look at other alternatives or build one if Zendesk don't get their act together. This fact alone could be leading many organisations to drop this service.
I find this utterly disappointing as a developer and its causing major issues with our system and your integration.
Hopefully Zendesk will sort this out before they start to loose a lot of customers.
Agree with Paul, this should be standard, especially given how much we already pay for our Enterprise Agent licenses. Pricing model from Zendesk actually forces people to look at alternatives and we will be doing exactly that next year.
Please sign in to leave a comment.