Views enable you to organize your tickets into lists using your ticket and user data. But if you’ve ever built a complex view with lots of conditions or a view that returns lots of tickets, you may have been less than happy with the time it takes to load and display the view. Complexity and volume can result in sluggish performance.
The purpose of this article is to provide some best practices that you can use to optimize your views in Zendesk Support. What follows is not a strict list of Do's and Don'ts, but rather suggestions for creating views that are optimized for performance and avoid unnecessary complexity.
To start, when building view condition statements, avoid the following:
Checking several text fields
Checking for a null value, e.g. "Assignee is ( - )"
Using broadly exclusionary conditions, e.g. "NOT" statements
Instead use inclusive conditions being as specific as possible
Checking for tags
Checking for ticket description in a condition for "does not contain the following string/word"
Checking for a string/word introduces greater complexity than checking for a tag
Conditions that check for tags are preferred to as "the lesser of two evils" over those checking for a word/string
Remember that displaying a view involves searching all of the unarchived tickets to find matches for the conditions defined in your views. It’s always best to define views that look for what’s there, not for what’s not there.
Manipulating large data sets
If you need to view an enormous volume of tickets (think hundreds of thousands of tickets for a year-end report for example), it may actually be better to first export your tickets into an external data warehouse outside of Zendesk Support and then pull your data from there.
Zendesk Support recently started automatically archiving tickets 120 days after they have been closed. You still have access to these tickets, but they are not included in views. You can read more about this feature here .
A view might contain so many tickets that the results are pages and pages long. The results are paginated, i.e. broken into separate pages of 30 tickets each. In the biz this is what's called a "large offset query" which can lead to a noticeable performance impact.
You might say, "But Jeremiah - what's the pagination limit?", to which I'd reply that it's less about a strict limit on pagination (although going beyond dozens of pages is going to make a view more complex) and more about these factors:
Volume of tickets
Number of agents accessing it at the same time
The "Query Stopper"
What’s the “query stopper”? It’s something that our team of Operations wizards put into place to prevent a massively large view from loading because of the processing power it would require.
Here are the two main reasons why this happens:
A view requires really complex calculation of tickets and/or a huge volume of tickets is returned.
Note : A personal view would only need a query stopper if it drew an enormous volume of tickets.
A view is heavily trafficked at one time (for example, hundreds of agents looking at a view at a same time).
What if my view requires some complexity?
A complex view opened just once a day is probably fine. When a view is opened for the first time on any given day, that will be the longest time it will take all day unless the cache is cleared at some point. The largest performance impact will be experienced when there's a very complex view, thousands of tickets are in it, and it's being accessed many times a minute by hundreds of agents.