Zendesk Views: Shared and Personal
A Zendesk shared view is a saved filter with a sort order. That sounds trivial. It's the setting that decides, every hour of every day, which ticket your team touches next.
What a Zendesk view is, and what it isn't
Three things make up a view. Conditions decide which tickets qualify. The sort decides the order they appear in. The columns decide how much an agent can judge without opening anything.
What a view is not: a report. Views show live ticket state, they do not show history, and they cannot tell you what happened last Tuesday. That is Explore work. People try to answer trend questions with views and end up with a list of forty saved filters nobody opens.
A view also cannot compare two tickets to each other. Conditions evaluate one ticket at a time against fixed values. There is no "show me tickets where the subject matches another ticket". Worth knowing before you spend an afternoon trying.
Zendesk shared views versus personal ones
Shared views are the ones that matter. They are your process, made visible, whether anybody designed them deliberately or not. You can restrict a shared view to specific groups, or to agents with a particular role, which is how you stop the billing team scrolling past thirty engineering queues.
Personal views belong to one agent and nobody else sees them. They are genuinely useful for an individual working style, and they are also where shadow process hides. If an agent has built a personal view that they work from all day instead of the team queue, you have two workflows and only one of them is documented.
Worth asking in your next team meeting: does anybody work from a personal view? If three hands go up and they've all built roughly the same thing, that's a shared view you should have made months ago.
Conditions: where it goes wrong
View conditions come in two blocks, one that all conditions must satisfy and one where any single condition is enough. Same structure as trigger conditions, different purpose, because a view evaluates continuously rather than firing once.
The three mistakes that show up again and again:
One useful habit: every view should answer the question "if this queue is empty, is there genuinely nothing to do here?" If the answer is no, the conditions are wrong.
Sort order is the real setting
Most teams tune conditions endlessly and never touch the sort. That's backwards. Agents work from the top. Whatever your sort puts at the top is what gets done, and everything below the fold is theoretical.
Sorting by priority alone fails within a quarter, because every ticket becomes high priority eventually. Sorting by created date is honest but ignores urgency. The combination that usually works: SLA target ascending, then created date ascending, so the thing about to breach comes first and ties break in favour of whoever waited longest.
Then check the columns. Requester, subject, created, updated, assignee. That is usually enough to triage without clicking. Ten columns means an agent reads none of them.
The view limit problem
Zendesk caps the number of active views an account can have, and the cap varies by plan, so check the current Zendesk documentation for your tier rather than trusting a number you read in a forum post from 2019.
Here's the thing: the hard limit almost never bites. The soft limit does. Agents cope with about seven queues. Past that they pick the first view that looks approximately right and work from it, which means views eight through forty exist purely to make the sidebar longer.
Two moves fix most of it. Deactivate rather than delete, so you can bring a view back if somebody complains. And check the view usage data Zendesk exposes for admins, because the views nobody opened last month are not views, they are clutter with a name.
The views most teams actually need
Five. Add a sixth if you have a genuine second team, and a seventh for a channel that behaves differently. Then stop.
Frequently asked questions
Which Zendesk view conditions cause the most trouble?
Time-based ones and nested ANY blocks. Zendesk view conditions evaluate on refresh, so a view built on hours since update looks unstable to agents who expect a fixed list.
What is the difference between a shared and a personal view in Zendesk?
A shared view is visible to agents you grant access to, optionally restricted by group or role. A personal view is visible only to the agent who created it, and admins do not see it in the shared list.
How many views can a Zendesk account have?
There is a cap on active views and it depends on your plan. Check the current Zendesk docs for your tier. In practice the practical ceiling is far lower, because agents stop reading a sidebar past roughly seven entries.
Can a Zendesk view compare tickets to each other?
No. Conditions evaluate each ticket independently against fixed values, so there is no way to filter on "similar to another ticket". Sorting by requester gets you close enough to spot same-person repeats by eye.
Why is my view showing tickets it should not?
Usually an ANY block doing more work than intended, or a missing status condition. Rebuild the conditions from scratch rather than editing, and test with a ticket you know should not qualify.
Do views update in real time?
They refresh frequently rather than instantly, and very large views can show approximate counts. If a number looks stale by a minute or two, that is normal behaviour rather than a fault.
The queue you cannot filter for
No view condition can spot the same question arriving more than once. Ticket Merger finds those pairs before an agent opens either one.
Start free trial14-day free trial. No credit card required.