A saved view is a filter on the ticket list that you have given a name, so that a combination you build often becomes one click instead of four. Most helpdesks have some version of this. The details of how ours behaves are not all obvious from looking at it, and two of them surprise people enough to be worth reading before you set them up for a team.
A view is a filter, saved as text
When you save a view, what gets stored is the filter itself — the status, the assignee, the search term, whatever you had set — recorded as plain text exactly as the ticket list expressed it. It is not a structured rule with its own editor. It is a snapshot of the query.
That design has a real benefit. Because the stored value is opaque text, new filters can be added to the ticket list at any time without anybody's saved views needing to be migrated or rebuilt. Views made two years ago keep working.
It also has a consequence. A view records what you filtered, not what you meant. A view called Escalations that is really status open plus priority urgent will keep meaning exactly that even after your team starts using a tag for escalations instead. Nothing will warn you; the chip will simply become slightly wrong. Views are worth re-reading occasionally for the same reason saved searches anywhere are.
Shared and personal, with nothing in between
A view is either shared with everybody on the account or personal to the agent who made it. There is no team-level or department-level middle tier, and choosing between the two is the only visibility decision available.
Shared views appear for every agent. Personal views appear only in their owner's list. That is genuinely useful — an agent can keep three half-finished experiments around without cluttering everyone else's chip strip — but be clear about what it is. Personal means hidden from colleagues' lists as a convenience, not protected from them as a security boundary. Everyone here is already a signed-in agent on your account with access to the ticket data underneath. If something genuinely must not be seen by a colleague, view visibility is the wrong control for it; account-level access is where that question belongs.
When you duplicate an existing view you get a copy prefixed with Copy of, owned by you and unpinned, regardless of whether the original was shared. That is deliberate: it lets you take a shared view, refine it privately, and share the result once it is right, rather than editing something the whole team is currently using.
The four you did not create
A new account does not start with an empty strip. Four views are created for you the first time the ticket list loads:
- Unassigned — open tickets with nobody on them. Every helpdesk needs this one, and its absence is what makes new tickets feel like they vanish.
- Urgent open — the on-call queue.
- Awaiting customer — the tickets where the ball is in the requester's court and you want them out of your main view. This pairs with the snooze workflow.
- Detractor follow-up — open tickets flagged from unhappy survey responses.
All four are shared with the whole account and pinned, so they show as inline chips rather than sitting in the overflow menu. They are a starting point rather than a recommendation; if Detractor follow-up means nothing for how your team works, it is meant to be changed.
Renaming or deleting a starter view brings it back
Here is the behaviour most worth knowing, because it looks like a bug when you meet it without warning.
The check that seeds those four runs every time the ticket list loads, and it decides what is missing by title. So:
- Delete a starter view and it returns on the next page load. Its title is missing, so it gets created again.
- Rename one and you end up with two. Your renamed copy stays, and the original title is now absent, so it is recreated alongside. Rename Unassigned to New tickets and shortly you will have both.
- Edit its filter and the edit sticks. Only the title is checked, so a starter view whose query you have adjusted is left exactly as you left it, indefinitely.
That last point is the way through. If a starter view is nearly right, change its filter and keep its name — that is the one form of customisation that survives. If you genuinely do not want one at all, unpinning it moves it out of the chip strip into the overflow menu, which achieves what deleting it was meant to achieve and actually persists.
The same rule explains a puzzle that occasionally reaches support: an account with two views called something like Unassigned and Unassigned tickets, created months apart, which nobody remembers making. That is a rename from a while ago, plus the seeder doing its job the next morning.
The strip reorders itself as you work
Views are listed pinned first, then by how often they have been opened, then alphabetically. The strip therefore rearranges itself over time to put your team's genuinely busy queues at the front, which is usually what you want and is briefly disorienting if you were not expecting it.
The usage count behind that ordering is best-effort. It is incremented in a way that can never delay opening a view, and if that increment fails it is dropped rather than retried. So the count is a good enough signal for sorting and is not an audit trail. Do not use it to argue about who uses what; use actual workload measures for that.
Pinning is the control you have over the order. Anything pinned sits ahead of everything unpinned regardless of use, so a queue that matters more than it is opened — a compliance or escalation view somebody must check daily — should be pinned rather than left to earn its place.
Two limits that truncate rather than complain
A view title is capped at 120 characters and the stored filter at 800. Both are enforced by cutting the value rather than rejecting it, so an over-long value is accepted and silently shortened.
The title cap is harmless; nobody wants a 120-character chip. The filter cap deserves a moment's thought, because a filter is only truncated if it is very elaborate — many statuses, a long search string, a list of assignees — and a filter cut at 800 characters may still load without complaining while quietly meaning something narrower than you built.
The practical rule: after saving an unusually complex view, open it once and check the result matches what you had on screen when you saved it. For anything simpler than that the cap is nowhere near reachable and you can forget it exists.
Views worth keeping
Teams that get value out of saved views tend to converge on a small shared set and treat personal views as scratch space.
The shared set is best kept short enough to fit on one row. A chip strip with fifteen entries is a menu, and people stop reading menus. Four to seven shared views, each corresponding to a queue somebody is actually responsible for, is the shape that works — and the fact that every shared view is visible to everyone means an unowned one is just noise for the whole team.
The most useful shared views are the ones that answer whose problem is this rather than what kind of ticket is this. Unassigned, awaiting customer and anything breaching a response target are all questions about ownership. Views that slice by product area or tag are usually better as personal views, because they map to individuals' specialisms rather than to the team's shared obligations.
Everything described here is available through the API as well, so a set of views can be created identically across several accounts rather than rebuilt by hand — worth knowing if you run more than one brand or workspace.
Put it into practice
- Adjust a starter view's filter, never its name. The filter edit persists; the rename gets you a duplicate.
- Unpin instead of deleting the starters you do not want. Deleting is undone on the next page load.
- Keep the shared strip to one row. Past about seven chips people stop reading it.
- Pin what must be checked rather than trusting the usage ordering to surface it.
- Treat personal as hidden, not private. It is tidiness, not access control.
- Re-read your shared views quarterly. They keep meaning what you filtered, not what you now mean.
- Verify one complex view after saving in case the filter hit the length cap.
Saved views are a small feature that quietly shapes how a team divides work, because the chips on that strip become the list of queues people believe exist. Choosing them deliberately, and knowing which of them will regenerate themselves overnight, is most of what there is to get right.