Best practices for creating views

In the Support ticket interface, views enable you to organize your tickets into lists based on a predefined set of ticket and user data. 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 be unhappy 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 views in Zendesk Support. It includes suggestions on how to create views that are optimized for performance. It also provides some information about views that can impact performance.

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. For example, "Assignee is ( - )"
• Using broadly exclusionary conditions. For example, "NOT" statements.
  Instead, use inclusive conditions that are as specific as possible
• Checking for tags
• Checking for a ticket description with a condition that "does not contain the following string"
  Checking for a string or word introduces greater complexity than checking for a tag. Conditions that check for tags are preferred over those checking for a word or string, but neither is ideal. 

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, rather than what’s not there.

Manipulating large data sets

If you need to view an enormous volume of tickets, it's better to first export your tickets into an external data warehouse outside of Zendesk Support and then pull your data from there. For example, if you're viewing hundreds of thousands of tickets for a year-end report.

Ticket archiving

Zendesk 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 broken into separate pages of 30 tickets each, which can lead to a noticeable performance impact. Some factors that impact performance include: 

• 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 Zendesk put into place to prevent a massively large view from loading because of the processing power it requires.

Here are the two main reasons why this happens:

• A view requires really complex calculation of tickets or a huge volume of tickets is returned.
• A view is heavily trafficked at one time. For example, if 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. 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.