Best practices for creating views

In Support, views enable you to organize your tickets into lists using your ticket and user data. For more information about views, see Using views to manage ticket workflows. 

If you’ve ever built a complex view with lots of conditions or a view that returns lots of tickets, you might have been less than happy with the time it takes to load and display the view. View complexity and volume can result in slower performance.

In this article, you'll learn 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.

This article contains the following topics:

• General tips
• Manipulating large data sets
• Pagination
• The "query stopper"
• Complex views

General tips

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.

Ticket archiving

Zendesk Support automatically archives tickets 120 days after they have been closed. You still have access to these tickets, but they are not included in views. See About ticket archiving.

Pagination

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 what's the pagination limit?", to which the answer is 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 the view at the same time
• Conditions

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).

Complex views

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.