| Announced on | Rollout starts | Rollout ends |
|---|---|---|
| April 27, 2022 | March 21, 2023 | March 31, 2023 |
Starting in Q1, 2023, we’ll be rolling out some changes to pagination in views and the sorting behavior on user profile pages. We are doing this to ensure the future performance and scalability of views, and to improve your overall user experience. This announcement explains what we’re removing and changing, what to expect, and what to do before it happens.
This announcement includes these sections:
- Why is Zendesk making these changes?
- Cursor-based pagination for views
- Changes to sorting user profile pages
Why is Zendesk making these changes?
As explained in our earlier announcement about changes to views sorting and ordering, there are some major infrastructure changes happening in the backend for Views. This is going to make the performance of views more consistent and less reliant on the scale and complexity of the view. Larger active ticket volumes will have less effect on the performance of views. This will also start to open up feedback improvements to the views interface that were previously blocked due to the technical limitations.
Cursor-based pagination for views
Zendesk is supporting a new pagination model called cursor-based pagination (CBP), and as part of this broader shift, we’ll be switching to cursor-based pagination in views as well. It allows for much faster response times than offset-based pagination at any page depth and improves the overall performance and loading time of the views.
This means that we are removing the ability to skip pages in a view. You will no longer see numbers as part of the page controls such as these:
Instead, each view will include page controls for First, Next, Previous, and Last.
What you need to do
We recommend that you create views with multiple, specific parameters to produce more narrowed views that surface more relevant information. For example, if you have a view where you typically skip to page 5 of 10 in order to see tickets assigned to a certain person or group, you can create a new view with an additional parameter for the assignee.
We recommend that if you paginate to find specific sets of tickets that you instead use the Views filtering capability to narrow down to that subset if tickets more easily.
Changes to sorting user profile pages
We will be removing the ability to sort tickets on user profile pages by Subject, Requester, and Group (see Viewing a user's profile in Zendesk Support). For example, if you click these column headings, nothing will happen. You will still be able to sort by other columns.
What you need to do
Make sure you understand that you will not be able to sort by certain columns on user profile pages in the future. Aside from that, no action is needed.
159 Comments
It's not as clear cut as that - we have staff at many different levels of knowledge. There are indeed classes of tickets that can and should be escalated, but it takes awhile even to reach the point of knowing that is so. And, at any given time, even among those who are relatively new and in training, they would have different levels of knowledge.
So, it is not uncommon for the pages to shake out like this:
Last page - the newbies have glanced at them, bounced off, and left them there. They may need escalation to T2 or higher, but nobody with the knowledge to evaluate that has looked at them yet. More experienced T1 staff will be working through this page as they have time.
Next-to-last page - there's some tickets on here that not-quite-so-newbies could handle, which they're looking at, and others that they can learn from, which they record so as to keep an eye on how they do end up handled.
Previous page from that - the newest newbies are here, looking at tickets nobody has looked at at all, handling the very easiest.
Your statement of "the newbies have glanced at them, bounced off, and left them there" right away tells me that they can't handle them and they could tag the ticket accordingly.
You could have a sliding scale for complexity
Each user which looks at the ticket which can not handle it moves the complexity up.
Maybe you have 3 view and new tickets and Very low sit in the first view for fresh users that just started they progress the tickets that they can't handle.
Tickets Low and Moderate are in the second
High and Very High in the 3rd
You could use a numbering scale if you wanted to provide more options. And create more views if if needed. The triage of the tickets was happening in how you are having users use the first/last pages, this just adds more structure to the process.
Even through you have multiple views it doesn't mean that users can action tickets in each of them. If one view is empty then they can action the next up or down in the list.
Just my thoughts.
Yes, creating a half-dozen more views to keep track of, on top of the dozen or so we already have, would *work* in a technically-functional but inefficient way. But why should we have to drag ourselves through knothole workarounds, when all we really need is to put the tool back the way it was that worked fine?
Ken Taylor Technically, you wouldn't even need new views for it.
You could also use the new filter functionality to let support staff filter the Ticket "complexity" that is ideal for them.
I do agree with you, that removing features is always a bad course of action.
But to be entirely honest, I'd rather Zendesk focus on other areas of development/switch to a sufficient backend to improve their platform. And I believe cursor based pagination is a part of that.
For us, due to the nature of some of our complex cases needing to be worked on, we don't always have an instant solution to each one and have cases on an On Hold status, whilst we solve the issue raised. As you know, the Play button doesn't work in instances such as these, as it will serve up the next ticket regardless of whether it's assigned already or not (as long as someone isn't actively viewing it). It's therefore sometimes easier to jump ahead a page or 2 (depending on the volume of colleagues we've got working on cases) and work through those manually, instead of using the Play button.
We also re-filter the view by Requester so that we can merge duplicates during Peak times and speed up responses that way, which is possible now for one person but was easier for multiple agents to do this together with the pagination view, hence speeding up the process rather than causing more work.
Essentially, we can make anything work but we shouldn't be having to change our entire workflow because Zendesk are removing features that were sold to us at implementation, some of which weren't even communicated with us before they were removed (eg automatic alphabetising).
Matthew W You're coming off as pretty needlessly condescending in this thread. Every team has their own workflows and use cases, and not every team dictates the same processes such as working all tickets in sort or SLA order. For example, one of the first things I do in the morning is run through our triage queue to clean out things like spam or irrelevant tickets, duplicates, or things that require escalation to our legal team. Due to the huge array of potential words and phrases used in these, it's not possible to use filters or build a view to capture them (much to my chagrin, as I've definitely tried). I also have ADHD and don't necessarily work in a linear fashion.
Views are also a very substandard workaround for this issue, due to the default and unchangeable maximum of twelve shared views being accessible on the sidebar. We work around this with the Quickie extension, but teams shouldn't have to add third-party extensions - let alone paid ones - to improve baseline functionality as a workaround for regressive changes.
Ziah Goodrow That is not my intent. I understand that each business has different workflows and leverage tools to meet their needs. I was just trying to provide suggestions to how views could be used to meet those requirements. The needs of a Tier 1 user verses a Supervisor are very different and cover a broad range of use cases. Views default filters, fields, and quick filters give the ability to isolate and order tickets. If these tools don't work then they don't. Understanding the reason is the first step. I would encourage people try these tools as they may find their workflow improved, but in the instance where it doesn't work to clearly state why as some have done and provided reasons.
I am sure Zendesk can provide better suggestions and best practice surrounding views and how to configure them that would mitigate some of the concerns in this thread. In the event they can't maybe with enough evidence they will rethink the change.
Bring the page numbers back! When working hundreds of tickets having the page number feature makes it much easier to jump from page to page.
This has been such a productivity waster. I really hope the backend has improved because the front end has been a slog ever since this change went through.
Please sign in to leave a comment.