This training material will cover the following topics:
As per Zendesk:
Views are a way to organize your tickets by grouping them into lists based on certain criteria. For example, you can create a view for unsolved tickets that are assigned to you, a view for new tickets that need to be triaged, or a view for pending tickets that are awaiting response. Using views can help you determine what tickets need attention from you or your team and plan accordingly.
When working with views, there are 3 things to keep in mind:
To create a view, you will first go to the admin panel by clicking on the gear icon on the left-hand side of Zendesk. From there, locate the Manage section and then click on the Views link.
Once on the view list page, click the Add view button on the top-right of the
page. This will bring up the view creation page.
On this page, you will enter:
Any agent means it is globally sharedAgents in a specific group means it is shared only to those in specific
groupsOnly you means you are making a personal viewPreview feature to be sure the tickets it pulls
are the ones you intended for it to pull.With all of that entered, click the blue Save button at the bottom-right of
the page to create the view.
To edit a view, you will first go to the admin panel by clicking on the gear icon on the left-hand side of Zendesk. From there, locate the Manage section and then click on the Views link.
Once on the view list page, locate the view in the list (if looking to edit a
personal view, you will need to change the filter on the left side below the
Add view button to Personal views) and click on the title. This will bring
up the view editor page (which is essentially the same as the view creation
page).
Once you are done making your edits, click the blue Save button at the
bottom-right of the page to save the changes.
There are actually two ways to deactivate a view in the Zendesk UI. The quicker
way is to go to the view list page, locate the view in question, hover over it,
and click the three vertical dots on the right-hand side. This will bring up a
sub-menu, which contains the option to Deactivate. Click that option and the
view will be deactivated.
The alternative way to deactivate a view in the Zendesk UI is from within the
view editor page. On that page, click the three vertical dots at the top-right
of the page, and click Deactivate view from the sub-menu that appears.
Note: Deactivating a view does not change its position. This value is retained in the backend. Re-enabling the view will have it take the same position it was in while previously active.
Because only 12 non-personal views can be shown to any one agent, positioning is very important for views. You cna make hundreds of them, but they won't all show (and if no one can see the view, it isn't very useful). As such, you need consider the following when creating/editing views:
To ensure all views we utilize are both consistent in nature and transparent in their actions, we strive to meet some standards on all views we work with.
The name used for the view should be simple, clear, and concise. You want the name to convey what the view is used for.
Generally speaking, we aim to make view conditions as simple as possible. When
possible, you should use condition sets that are very specific and succinct. As
an example, if you wanted a view to only run when the form is Support Ops, it
is better to simply put a condition of "Form is Support Ops" than adding
exclusions for every other form. This can take time and practice to learn, so
when in doubt, pair with the rest of the Support Ops team!
Note: While the above video is for Zendesk Automations, the exact same process applies for Zendesk Views. The sole difference is the tags used on the requests and merge requests.
When it comes to making changes to Zendesk views, we utilize the zendesk-views repos instead of doing this via the Zendesk UI. This allows us to easily revert a change and ensure what is running in our production instances is what we have approved. To ensure each runs smoothly, we do our changes in set stages.
All Zendesk view changes should start with a request issue. This issue should stem from a support-team-meta issue where the proposal was discussed.
The request should not be "make this change in Zendesk," unless the request is coming directly from a Support Ops team member. If the request does not detail what the desired effect is, we as Support Ops should instead push back on the request and ask the requester detail what they want to see as a result and not what they want done in Zendesk.
All request issues should contain the following labels at creation:
While we have scripting and templating in place to find when these are missing, you should strive to ensure those are present. If you find any of them missing, please add them.
Once the request is in good standing, you may assign it to yourself (if it is not already) and add the tag "SupportOps::Doing" to indicate you have started working on this.
When making a change to Zendesk views (whether it be creation, editing, or deactivation), we start the process in the Zendesk sandbox. In the Zendesk sandbox for the corresponding Zendesk instance this impacts, you will make the desired changes. Once this is done, update the original request issue with the following:
/spend X minutes, where X is the number of
minutes you spent.You will then test these changes. This process should take no less than 3 days after making the changes. This is to ensure that not only is the change tested thoroughly, but others have time to review your tests and the results.
Often, you will need assistance testing out changes. Should this be required, consider reaching out to the following for assistance in testing the changes:
If testing provides failed results, this means we need to update the original request issue with what happened and why. If this is because of a flaw in the request, we should state as much and recommend the requester go back to the original support-team-meta issue to re-discuss. If it failed due to our implementation, we should detail what was wrong with the implementation and propose a new method to try.
Once the changes have been thoroughly tested (and are successful), make sure to add the time you spent doing the testing to the original request.
At that juncture, update the issue with a comment to state testing has completed and was successful. You should give the requester an opportunity to review the test(s) and result(s). Ask if they would like to review them. If they decline, you may move on. If they wish to do so, await their update after they have reviewed the results.
To prepare for the implementation, you will need to create a merge request to the corresponding zendesk-views repo (see Useful links down below).
For an existing view, this is a simpler approach, since the view already has an ID in Zendesk. Make the edits to the file in the repo and submit the merge request in draft mode.
For new views, this gets a bit trickier, as there is not an ID in Zendesk as of yet. To help with this, clone an existing view and then deactivate the cloned copy. You can then use this new views's ID value in the merge request.
After creating the merge request, make sure it is linked in the original request and you have added any additional time spent to the requester issue.
From here, have one of your fellow Support Ops team members or a Support Ops Manager review the merge request and add their approval (or comments). Once approval has been added, an implementation date can be determined.
Note: All merge requests in the zendesk-views repo should contain the following labels (the same as with issues):
Once an implementation date has been determined, you need to announce this upcoming change. To do this, use the following template:
As per the request ISSUE_LINK of REQUESTER, we are planning to implement BRIEF_SUMMARY_OF_CHANGES. This is slated to be done on DATE. The impact you might see is BRIEF_SUMMARY_OF_IMPACT.
You will announce this in two places:
#support_operationsAfter posting, you then want to cross-link (copy the link to the post) the
announcement in the slack channel #support_operations to the following
channels:
#support_team-chat#spt_managersThis stage should be the simplest one to implement, as you already have a merge request ready to go! Simply mark the merge request as ready and merge it. If you encounter any issues here, reach out to your fellow Support Ops team members for assistance.
Once an implementation has been completed, you need to announce it! To do this, use the following template:
As per the request ISSUE_LINK of REQUESTER, we have implemented BRIEF_SUMMARY_OF_CHANGES. The impact you might see is BRIEF_SUMMARY_OF_IMPACT. Please direct any issues/comments/feedback you see to the issue linked above.
You will announce this in two places:
#support_operationsAfter posting, you then want to cross-link (copy the link to the post) the
announcement in the slack channel #support_operations to the following
channels:
#support_team-chat#spt_managers