Let’s say you’ve got a new feature request. You need to create a trigger that handles severe security tickets. Once the trigger discovers such a ticket, it’ll escalate the severity and assign it to the security group.

As this is a fairly sensitive change, you’ll want to build it in your sandbox first. So let’s say you do that, test it, and it works great. Now you want to promote it to production. But all you Zendesk pros know that your work is only half done because you can’t simply “promote” something from the sandbox to production with the press of a button.

In this article, I explain why today’s primary method for doing this—rebuilding that configuration manually in production—can’t scale, and what to do instead.

Anywhere you repeat yourself, you invite human error

Rebuilding your trigger (or whatever you’ve built in the sandbox) in production has pros and cons. Because you’ve done it before, so it should be quick. But because you expect it to be quick, you may rush and miss something. While building directly in production, you might leave out an important condition that you caught when you tested it in the sandbox.

If you’re making lots of changes, the cons quickly start to outweigh the pros. Rebuilding all those configurations manually tends to:

• Introduce errors—if you leave out a condition or misspell a tag name, the ticket won’t do what you programmed it to. And worse, you’ll think it’s working.
• Not scale—if you have dozens of business rules to promote, it slows you down considerably. If you have many instances with hundreds of rules, it slows progress to a grind.
• Consume a lot of time—every feature release takes, well, twice as long. Maybe more, given how careful you have to be when you build in production.

Fortunately, this is something Salto can help with. (Full disclosure: You’ll need a Salto license for this. Request a demo here.)

‍

‍

Safely promote changes and sync your sandbox using Salto

If you know how Salto works, you know it reads all your Zendesk configurations and displays them in a format where you can more easily work with them. It can also write the configuration back to Zendesk. That means there’s nothing stopping you from moving a configuration element—that new trigger for escalating security tickets—from sandbox to production.

And what’s more, you can actually copy things back and forth. So once you’ve moved your trigger over to production, you can “sync” your production back with all your sandboxes, so they’re all up to date.

Here’s how to do it, step by step:

1. Log into Salto to connect your instances
‍Ensure you have both your sandbox and production instances connected. Run a fetch on both environments. (This will grab the latest configuration.)

2. Click on the “deploy” tab and create a new deployment
‍Select your source environment (in this case, the sandbox) and the target environment (in this case, production). You can give the deployment a title and a description. Then select “create deployment.”
‍

3. Compare the environments and see the differences
‍Now, you will see the full comparison of your sandbox and production (which is pretty valuable in and of itself!). You should now also see the differences between those environments.

Elements with the production color exist in production. Elements with the sandbox color exist in the sandbox. And elements with two bullets, one of each color, exist in both instances, although their values will be different.
‍

4. Move the changes to production Within the sandbox, find the trigger you want to change. Select it and make the desired change. Does that change look good? Let’s move it to production. Find the trigger in the sandbox and select it.

Now, you should see that the “related elements” tab just changed. Click it. It will show you any elements it relies on. In this case, you will see the ticket field that this trigger uses. Promoting the trigger without it just won’t work. So, select this field and click the Salto “refresh” button. Salto will now calculate if there are other elements that depend on the field you just selected. Here, the answer is no, so we are good to go. Click the “preview plan” button.
‍

5. Review and deploy the change
‍The deployment is now locked in for you. You can review the planned changes and do some last- minute changes if you like by clicking on the “edit” button and editing the change. If it all looks good for you, go ahead and click “deploy.”
‍

6. Review your completed change
‍Just wait a few seconds for the deployment to complete and that’s pretty much it. You finished your deployment and your changes are now in production. You can also see the list of all the previous deployments under the Deploy tab.

And if you want to back-promote changes from production back to one or more sandboxes, you can simply repeat this process, starting with production.
‍

Goodbye human error

Zendesk is powerful. It’s flexible. It makes adding rules and changing things very easy. That’ll help your business scale quickly. But when you have to manage multiple Zendesk instances at scale in an environment where customers and the support team are relying on you, it could use some structure.

By managing Zendesk according to the application lifecycle, you’ll reduce errors, retire tech debt, and make your support even more reliable.