Zendesk Advanced Search
Most agents type words into the box and scroll. Ten minutes with Zendesk advanced search operators turns that box into the fastest tool in the interface.
The shape of a query
Zendesk search is fielded. A term on its own searches text; a term with a property in front of it filters.
type:ticket status:open group:billing
type:ticket requester:sam@acme.com created>2026-09-01
type:user organization:"Acme Ltd"Three rules cover most of it. Quote any value containing a space. Prefix a term with a minus to exclude it. Use the comparison operators on dates and on ordered fields such as status, where status<solved means everything still open in the useful sense.
Everything is ANDed together, which is why a query that returns nothing is usually one condition too specific rather than a syntax error.
The Zendesk advanced search operators that do the work
ticket, user, organization, group. Without it you get a blended list, and half your other operators won't apply.status<solved is the single most useful token in the whole syntax.requester:, assignee:, submitter:, cc:. Email address or id, and assignee:none finds the unowned.created, updated, solved, due_date, each taking >, < or an exact value in YYYY-MM-DD.custom_field_360001:value.Operator names and the exact comparison support do shift between releases and differ slightly from the Search API, so check the current Zendesk docs when a query behaves oddly.
Queries worth saving
Bookmark the search URL, or rebuild them from memory. Either way, these five earn their place.
Unowned and ageing, the first thing a team lead should look at each morning:
type:ticket status<solved assignee:none created<2026-10-01Everything from one company still open, which is what you want the moment an account manager calls:
type:ticket status<solved organization:"Acme Ltd"One requester in a narrow window, the fastest manual duplicate check there is:
type:ticket requester:sam@acme.com created>2026-10-10Tagged for a known bug but not yet linked to the problem ticket:
type:ticket tags:bug_4471 -tags:linked status<solvedReopened work, which is the quality signal nobody reports on:
type:ticket tags:reopened updated>2026-10-01People and organisations
Half the searches an agent runs aren't about a ticket at all.
type:user email:sam@acme.com
type:user role:end-user organization:"Acme Ltd"
type:organization name:acmeUser search is how you find the duplicate person: two records for the same human, one with a typo in the address, each holding half the history. Searching by name rather than by email surfaces the pair, and tidying that up is a separate job from anything you do to tickets.
Organisation search earns its place on B2B accounts, where somebody asks what a client raised last quarter. Find the organisation, then pivot to type:ticket organization:"Acme Ltd" created>2026-07-01 and the answer takes two queries.
One habit worth forming. When a search returns nothing, remove one condition rather than rewriting the query, because nine times out of ten the culprit is a date bound or a tag that never existed.
Search versus views
They aren't competing tools, and teams treat them as though they were.
A view is for standing work: a queue somebody looks at every day, shared, sorted, with a count in the sidebar. If you would rebuild the same query tomorrow, it should be a view.
Search is for questions. One-off, exploratory, often about the past. Search reaches things a view cannot, including closed and archived tickets, which is precisely why you go there when somebody asks what happened in July.
One practical caveat: indexing is not instant. A ticket created seconds ago may not appear yet, and that lag has convinced more than one agent that search is broken when it's merely behind.
The traps
Archived tickets don't behave the same way. Closed tickets get archived after a period, and archived tickets are searchable in a reduced way, so some field-level queries quietly stop returning them.
Suspended tickets are not in the normal index at all. They live in their own view, and a search for a customer who swears they wrote in won't find the message sitting in suspension.
Deleted is gone. Merged is not: the closed side keeps the closed_by_merge tag, so type:ticket tags:closed_by_merge is a fast way to count how much of your volume was duplicated.
Frequently asked questions
Is the Zendesk search syntax the same in the API?
Yes. The Zendesk search syntax you type in the agent interface is the same query language the search API accepts, which makes the search box a decent place to test a query before you code it.
Does Zendesk advanced search support OR?
Standard search treats terms as AND. Some operators accept multiple values and behave like an OR within one field, and the Search API is more flexible than the interface. Check the current docs.
How do I find tickets with no assignee?
Use type:ticket assignee:none status<solved. Adding a created date bound turns it into a genuinely useful morning check.
Does Zendesk search closed tickets?
Yes, though archived tickets support a narrower set of query conditions. If an old ticket will not surface with filters, try the plain text search first.
Can I search inside attachments?
Attachment filenames are searchable in some contexts; content inside a PDF isn't indexed. Do not build a workflow that assumes otherwise.
Should I save searches or build views?
Build a view for anything you will run more than twice a week. Keep search for one-off questions, and remember views cannot reach archived tickets.
Stop searching for duplicates by hand
That requester-plus-time-window query is a manual version of what Ticket Merger runs continuously, then merges without anyone looking.
Start free trial14-day free trial. No credit card required.