In this article, I'll show you how Salto deployments can increase your Zendesk premium sandbox ROI by bypassing all the sandbox replication limitations.

‍

Zendesk Sandboxes

A Zendesk sandbox is another Zendesk instance that mirrors some aspects of your account setup.

It's meant to be a safe instance where you can create new triggers, macros, etc., and test them before releasing them to production.

Depending on your sandbox type, your sandbox will be either a brand new empty instance or something that looks very similar to your production instance.

When the sandbox is created, Zendesk copies some of your production instance setup, known as replication.

Unfortunately, this replication is not perfect and presents several issues:

‍

Replication frequency‍

Your sandbox starts drifting away from production as soon as it is created. This is because changes you make in production will not be reflected in your sandbox. As time passes, your sandbox is more and more out of sync. To fix this, you have to trigger a new sandbox replication.
‍

However, you cannot trigger a sandbox replication at any given time. How often you do it depends on your sandbox type:

• Premium - metadata copy: 5 replications per month
• Premium - partial copy: 10 replications per month
• Premium - production copy: 15 replications per month

If you need to replicate new changes made in production but have already run out of replications per month, you will have to wait before you can replicate those changes.

This makes the sandbox less valuable because it is not an accurate replica of production.

Another challenge is that for large instances, the replication can take from 5 days, up to several weeks. Those are weeks where you cannot do any development because you are essentially waiting for the sandbox to be ready.

‍

Losing your work

‍

When you can finally trigger a new replication, all the configuration in the sandbox that doesn't exist in production will be deleted. Any “work in progress” configuration will be deleted, meaning that you cannot refresh your sandbox while in the middle of a project.

It is also impossible to decide which parts of your configuration you want to replicate. Say for example you want to replicate only the triggers that were created in the past 6 months and leave everything else as is.

The replication deletes the sandbox and creates a new one based only on what exists in production.

‍

Replication Limitations
‍

On top of that, the replication has a good list of limitations. One of the most shocking ones is that while your triggers are copied, their order is not.

‍This means your triggers will be in a new random order. If you are a seasoned Zendesk expert, you know that the order in which your triggers run is crucial, and something needs to be done carefully.

If you have more than 100 triggers, you'll have to spend a lot of time reorganizing them.

Another side effect of these limitations is that after every sandbox replication, you need to spend a lot of time ensuring everything is configured correctly. So even if you could replicate your sandbox every week, you probably wouldn't do it because of the effort required to bring up to speed.
‍

Zendesk deployments with Salto

With Salto, you get bi-directional and unlimited replication between your sandbox and production instances by using what is known as a deployment: An easy way to replicate configuration between any two Zendesk instances.

This means you can replicate changes from production multiple times a day without overriding any other existing configuration in the sandbox.  
‍

At the same time, you can replicate changes from sandbox to production. This allows you to create new triggers, macros, etc., test them out, and then deploy them to production in just a few clicks.

You can also choose exactly what you want to replicate. In the example below, I only want to replicate one group, one macro, and two triggers.
‍

Want to see it in action?

Getting the most out of your Zendesk sandbox

With the ability to deploy changes from sandbox to production and vice-versa, you can now make the most out of it.

You no longer need to wait for the next replication cycle, nor will you spend time ensuring that the sandbox is an accurate replicate. Instead, you can focus on what really matters:

Build features to give your customers the best customer experience possible.