Zendesk is the support platform of choice for 100,000 companies that support hundreds of millions of customers. It’s flexible. It’s intuitive. But as you know, it’s a bit… open-ended.

Even a mid-sized company is likely to have multiple instances, hundreds of triggers, and the difficulties of global scheduling. Zendesk is simple and easy to configure, and that helps companies scale. But once they’ve scaled, they’re left with a high maintenance burden. That can prevent them from launching more instances or building it out further.

The consequences of working this way, and with many people making configuration changes directly in production, are actually quite serious. In this article, I’ll explain how to implement a framework we use in software development—the application lifecycle. It’ll help you reduce errors, avoid configuration tech debt, and make your support even more reliable.

For inspiration, look to software development

I like to draw the comparison between business systems management and software development. In software development, the complexity is higher. There are more components, services, and dependencies. But high-quality software tends to be more reliable than most business system implementations because with the former, you have the methodologies and tools to manage that complexity.

For instance, with software development, you have ways to:

• Plan and collaborate on changes
• Document your work
• Test—including unit testing, integration testing, and continuous integration
• Save past versions (with git)
• Deploy changes from sandbox to production
• And more

These are the building blocks of the modern application lifecycle management process. In business systems, you don’t have those same methodologies to manage the systems’ configuration. Nor are systems like Zendesk designed to help you manage their configuration at scale. The interface makes it easy for users and sysadmins to create and change things, but very difficult to tell what’s changed, who changed it, and why—as well as the implications.

‍

‍

In fact, there isn’t even one birds-eye view where you can see what’s configured in the first place. You can be the sole system owner and not know what’s precisely in the system.

This is a problem if you’re trying to debug Zendesk triggers which fire sequentially, top to bottom, through the list. (And sometimes, fire multiple times.) But if you want to add a new trigger, where do you add it? To the top? To the middle? That’s tough to know. Imagine what it’s like for someone new to the team. They have to open every trigger, one-by-one, to piece the puzzle together.

If this were software development, you’d have more control. You’d have a big, searchable code base. It’d act as one blueprint of everything that exists. If you had that, you’d be able to search through those triggers, and, without clicking into them, see which one is misfiring and make minor tweaks.

And that’s just one example. There are lots of areas where Zendesk isn’t up to the task of managing itself. Take Zendesk sandboxes. At the time of writing, admins who build something in a sandbox cannot “deploy” it into production. Instead, they have to build it again, which introduces the potential for human error.

And as your business really starts to grow, there’s the challenge of managing multiple Zendesk instances—possibly a dozen. Whatever you do to one instance, you must do to all, or they’ll drift out of sync. If they drift too far out of sync, now you’re managing twelve different systems.

For all these challenges and more, the application lifecycle can help.
‍

Using the application lifecycle in Zendesk

Below is a diagram of the application lifecycle. It works just as well for organizing business system development as it does for building and maintaining software.

I recommend dividing your Zendesk configuration effort into these five steps: plan, develop, test, deploy, and maintain. Today, most teams simply develop in production and occasionally test in the sandbox. But if you want to avoid errors, buggy triggers, and a landslide of emails from customer success managers, it’s best to run every substantial change through this flow.

You can manage these stages on a Kanban board in a project management tool like Jira, Asana, or Monday.com. This’ll force you to plan. It also lets you share what you’re thinking with others—like admins in other regions. Say you want to rewire an automation. Now, you can invite others who are dependent upon that automation to review your proposed change.

Then, always develop and test in the sandbox before you deploy. While cumbersome, this will force you to think through your releases and catch mistakes.

And if you go a step further and document your changes as tickets which include the reasoning behind them in Jira or ServiceNow? That’s where things really come together. Now you’re preserving a record of the stories around how things were built and why, which new users can find and read.

And if that all sounds very manual, here’s where Salto can help.

Salto customers can use our Zendesk adaptor to pull their configuration and metadata into one place where you get that singular blueprint stored in a version control system like git. Now, you can truly manage the full lifecycle because instead of hunting through the interface, you can search through your entire Zendesk configuration across each instance. It gives you extra tools to compare instances, see differences, and align them. It lets you understand relationships and dependencies—like what will happen if you move an entire Ticket Category. It allows you to get alerts for important changes, and—this is the big one—you can deploy configurations from sandbox to production with one click.

(In the words of one Salto user, “It makes the Zendesk sandbox work like a real sandbox.”)

You can also selectively sync pieces of different instances to each other, so you can align the sandbox to production without erasing unsaved work.  

And if you have all that in place, you can manage the full application lifecycle in Zendesk.

‍

Plan: Understand the effects of changes before you make them

Whether you make changes in your Zendesk instance or Salto, it will update in both systems. With a complete record of what exists, you can run searches and “find and replace” functions without having to click into a particular trigger or automation. Because you understand how objects interact, are dependent, or are referred, anyone—even new hires—can know what exists and why.

That allows you to plan out changes, gut-check them, and invite others to discuss.

‍

Develop: Collaborate on changes, version, and peer-review

Salto allows you to maintain multiple pre-production environments to create a development pipeline. (Here’s an example in Salesforce.) Salto pulls your configuration into git where you and the team can branch and fork versions of the configuration, review proposed changes, and push those updates through the pipeline.
‍

Test: Easily compare instances

Push whatever you and the team have built into the full sandbox. Run tests, including with users, before you push it into production.

‍

Deploy: Deploy metadata to and from instances, and if needed, revert

If the configuration checks out, push it into production as an update. If something goes wrong, revert by pushing the pre-update version back into production. (Remember, Salto is saving each prior version.)

You can also “back-promote” updates from production back to your sandboxes to keep them in sync. (Because your configuration is saved in Salto, and editable, your partially completed work is saved. Refresh the sandbox as you would normally, then select that configuration you were working on and push it back into the sandbox.

‍

Maintain: Get alerted when someone changes your customizations

Salto gives you a place to track and see who made what changes—including to any automation, trigger, or macro. You can set alerts so you’re notified of changes to configurations that matter to you. (Just select the configuration and whether you’d like the alert via email or Slack.)

And finally, you can troubleshoot and assess requests. Salto helps you understand dependencies and references so once you return to the planning stage because someone requested something, you don’t need to add it to your towering backlog. Instead, you can simply glance in Salto and see what it might affect.

Manage the Zendesk lifecycle and stay sane

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.