Zendesk instances are complex by their very nature. A series of fields, triggers, automations, forms, rules, user permissions, group permissions, Etc all fit together to build efficient workflows for your agents and customers. But as any support team grows, new features and functionality are added to your products and services, and areas of automation are found, you inevitably need to make changes to your configuration which will have an impact on other workflows within your organization.

Zendesk has provided some useful features to help with testing changes. For example, the sandbox functionality which allows you to test changes outside of your production environment first. Sadly, these are often not utilized with best practices and your sandbox is not always a fair representation of your production environment. This is where impact analysis becomes absolutely critical.

Defining Impact Analysis

Impact analysis is the process where you assess a change based on not only the workflow or objects you intend to add or  alter, but all other workflows and objects that interact with the change. For example, a trigger that sends a customer facing notification may not be required for a given workflow but may have a rule which runs for all workflows that may not be ideal for your new workflow. Or a trigger requires reference to a new field you created in your sandbox, so you need to migrate the field first as a dependency.

Impact analysis is  always a best practice. It is most useful when you have multiple administrators working on the same instance or a lot of complexity in your environment. In this article we're going to explore how impact analysis can be used to ensure that fewer mistakes and bugs are introduced in your production environment.

How to conduct Impact Analysis

The basics of impact analysis rely on understanding the overall architecture and ownership of the Zendesk instance to be changed. This is made easier by using best practices for maintaining Zendesk. Once those practices are in place, it's essential to have a structured framework to assess the potential effects of changes on various aspects of the organization. Your framework should include the following types of details:

Scope definition

This is the scope of the changes being made and why they are being made. It should include: 

• The team(s) requesting the change
• Business need for the change and intended outcome
• Timelines
• One or more potential solutions to explore (each of those could change the categories or dependency steps of the document)

Stakeholders

This list should include any leaders or administrators who work with Zendesk. It also may include agents or people designated to test the changes.

Impact categories

There are many types of categories of impact. Everything from 'system down time' to 'reputational harm.'  With Zendesk, most will fall somewhere in between. Not all categories will be relevant for all change types. Here are some examples:

Instance impact: This is by far the most likely and common category. Zendesk, to its advantage and also to its detriment, reuse objects across all workflows, brands, issue types, etc. by default.  When making a small change to, for example, a trigger, that could impact other issues that use that trigger unless the trigger rule is specifically designed not to. Doing this manually is difficult, and using a tool like Salto will help you increase accuracy and speed in finding all the potential instance impacts.
‍

Support outage: This is the possibility a channel of support communication is broken. This could include breaking email verification, taking down a contact form or the knowledge center, editing notification triggers or automations, etc.

Operational change: This could be a change to or addition of an integration, edits to one or more views, changes to any routing triggers, etc. Any change that could impact a documented workflow that support follows. Note that this could also include the change to a third-party tool. For example, if you swap payment systems, the workflow for agents in Zendesk will need to change.

Customer Experience change: Will the change impact what the customer currently experiences? For example, branding, change of communication channels, new policies or automations, the introduction of AI tooling, etc.  An example here might be the depreciation of an entire channel, that is both a significant Operational and Customer Experience change.

Legal Impact: If you are introducing new data collection or AI tooling, it is important to understand the legal implication of storing that data or the requirements of certain countries when it comes to AI communication. For example, the EU AI Act stipulates that you must notify "a person of their interaction with an AI system and flagging artificially generated or manipulated content."

Dependency Analysis

Once you know all the categories of impact, it is time to analyze the remediation of those impacts. There are two types of dependencies that need to be looked at:

1. The easiest one is when one object needs to reference another that does not yet exist in the target Zendesk instance. For example, in your sandbox you created a form which references a newly created field that is not in production. The form is dependent on the field being there, so the field must be created first.
2. The other is about the impact of the change. For example, if 'Workflow One' requires use of 'Trigger Two' and you are adding a new 'Workflow Three' to the instance, will the rule for 'Trigger Two' fire? Should it? This type of dependency requires more research and will either involve stakeholders to make that determination or require further change, which will require its own impact analysis.

Communication Plan

One of the most underutilized aspects of impact analysis is communications. Agents and customers coming in one day to find new things that were not expected, unannounced, or, at worst, full of bugs. All changes have some impact. How that is communicated may change depending on the scope of the change as defined in the 'Scope Definition' section. However,  some communication is required in all cases.

Monitoring and Evaluation

The final section is a plan on how the change will be monitored and for how long. Who owns sign off that the change was successful or if the decision has to be taken to roll a change back. Some changes can be immediately signed off on, and others may require a few hours or days or even weeks of monitoring. Having a plan in place to ensure this step is taken will improve accountability and decision making if something goes wrong.

The Impact of Change

Every change has an impact. From something small like an addition of an option in a Drop-down field where trigger, reporting, and other automation dependencies should be looked at, to a massive change such as launching a new Zendesk Bot, where your all your workflows need to be evaluated - all changes have an impact. Conducting a well planned impact analysis is a vital part of Zendesk configuration maintenance.