By its very nature, Customer Support is ever evolving and as such your Zendesk configuration needs to change with it. These changes might be small, such as the addition of an automation or a tweak to an agent signature, or they may be large like the introduction of a whole new ticket workflow. No matter the size, they all impact your production and have the potential to destabilize your support operations or alter your customer experience. That is why a proper plan to backup and restore your Zendesk configuration is necessary for all Zendesk Administrators.

Why is this a problem?

In general, Zendesk lacks any sort of version control and robust auditing. Depending on the object, you either get no visibility of who or why an object changed (for example, with a Form) or only basic meta data such as a date of last change (for example, with a Field). 

The impact of this is significant. As your Zendesk instance grows in complexity, a small change to your configuration may have farther reaching implications than you expected. It is especially true if you have multiple brands, ticket types, teams, geographies, or Zendesk Administrators. If an object is deleted, you might be left with very few breadcrumbs to try and piece together what it was. For example, with a deleted trigger you may be able to know what changed, but not why or by whom.

‍

These breadcrumbs and inconsistent audit capabilities make troubleshooting configuration errors difficult or even impossible.

Solutions

There are several ways to solve the problems above. They range from very manual to full automated. Let's explore a few.

Sandbox

Some might consider the Zendesk Sandbox as a place to backup your configuration. It is possible to use this feature for that purpose, but it isn't its intended purpose. The sandbox feature is meant to be used as a testing area for new functionality without impacting your production environment. While it may contain elements that are similar to production, you will need to watch that anything you want to copy from your sandbox to production doesn't contain additional changes as well. (Note that, for the same reasons as discussed above, it may be hard to pinpoint who and when a given object was edited in the sandbox.) Sandboxes also do not have a migration feature or a dependency indicator, meaning that moving objects between the environments is a manual task and may have order dependencies. For example a Field referenced in a Trigger must be copied to the production instance first before the Trigger can reference it.

Organization and Description Fields

Organization and describing your configuration is more of a best practice, but it is so rarely done in production that it needs to have more attention drawn to it. Simply organizing things better can really change how you manage your Zendesk instance and the speed at which you can restore a configuration. For example, trigger organization with meaningful names, and descriptions of what workflows use them, and why they exist is a great start.  

A good description should explain why a trigger, automation, field, etc. is there, which teams, workflows, reports, etc. rely on it, and, most importantly, reference to things like:

1. Who to contact if changes are required
2. A link to workflow docs or change management process docs
3. Purpose of the object

For this method to work, every time an object is updated the description needs to be updated as well to explain what was changed, why, and by whom.

Workflow Documentation

One of the most common solutions to the backup and restore problem is thorough documentation of each workflow. There are two components of workflow documentation that are required to restore a configuration.  

1. The workflow diagram for each unique ticket workflow stage. This could include things like:some text
   • Routing and Assignment
   • Categorization
   • Satisfaction surveys
   • Notifications
   • Re-opens
2. A description of each object used in the workflow (these can often be screenshots of the definitions within Zendesk)some text
   • Macros
   • Triggers
   • Automations
   • Fields

When a change is required, the appropriate document is updated, including any workflow changes and any differences in the object. The main benefit of doing this is that the documentation itself can be version controlled using a Document Management System. Using a DMS you can capture a configuration and restore to a given state pretty easily. This method also has the added bonus that these documents can be used by the team for training purposes.

Export/Import via Zendesk Support API

The Zendesk API can be used to backup and restore configurations. Using the endpoints for each object, you can export the definitions in a human-readable form which will allow you to compare objects or detect missing objects. This method works best with robust documentation, since even with triggers and automations definitions exported, how these objects are used in practice can be hard to determine without a detailed explanation.

The downside is that an administrator either needs to remember to export the objects they edit, or build and maintain scripts which do the export on a regular basis. Manual steps.

Change Management Apps

The Zendesk Marketplace has a few Change Management Apps that will help prevent accidental changes/deletions. While change management doesn't explicitly help with backing up and restoring, a common practice to enact change in a robust and auditable way could reduce the need to restore at all since mistakes should be caught earlier. Change Management practices are likely best paired with other solutions to provide structure to Zendesk changes and facilitate restoration of configuration.

A Business Application Manager

The most robust way to backup and restore your Zendesk configuration is with the use of a business application manager solution, like Salto. These tools have backup and restore capabilities that allow you to fully automate these processes. Salto automatically backs up and version controls Zendesk objects, notifies you of changes to objects, identifies all dependencies, and allows you to restore one or more configuration changes in a few clicks. 

Required Process

A consistent, tested backup and restore process is required for any Zendesk implementation. Processes, automations, administrators, integrations, etc. will always change over time and without these mechanisms in place, there is a high probability of impact to your agents and potentially your customers. Zendesk lacks built-in audit capabilities, dependency checking, usage metrics, and other features that can solve these problems. One or more of the solutions above should be considered to ensure business continuity.