Search across Auralis
On this page
Auralis has several searches rather than one, each scoped to what it sits on. Knowing which is which saves the commonest wasted minute in the product: typing a ticket reference into the wrong box.
The command palette is navigation, not search
The palette — the quick-open panel over the interface — lists destinations, not results. It filters a fixed set of places: the inbox, conversations, customers, knowledge, the AI workforce, outcomes, migrate, voice numbers, workspace settings, documentation, the API reference.
Type a ticket reference or a customer's name into it and it will honestly say No matches, because it never looked at your data. It is the fastest way to get to a screen, and it is not a global search. There is no global search.
Ticket search
The search box above the inbox covers reference, subject and body, and it looks at the customer's name and email address as well. Press Enter to run it.
Two things to know about it:
It runs inside your current filter. Narrow first — to your own tickets, to a team, to a status — and then search within that. This is the whole technique, and it is why the filters matter more than the search box.
There is no query syntax. No from:, no quoting, no boolean operators. It is a plain substring match, so a fragment works and a clever query does not. Structured narrowing is what the filters are for: status, priority, source, tag, assignee, team, customer, overdue, snoozed, tickets you created, tickets mentioning you.
When a combination proves useful, save it as a view. A saved view stores the same set of filters, which is why anything the filters can express can be saved and anything only the search box can express cannot.
Customer search
The customers list has its own box, over name, email, company and phone. Again, press Enter, and again there is no syntax — though it is careful about one thing: an underscore in what you type is treated as an underscore rather than as a wildcard, so searching for a literal first_name finds it.
Help-centre search
The search on your public help centre is the one real full-text search in the product, and it behaves like one.
Results are ranked by relevance, each with a highlighted snippet showing the match in context and breadcrumbs showing where the article sits in your tree. The total counts every hit, not just the page you are looking at, and results page rather than truncating.
Two properties worth relying on. The query lives in the URL, so a result set is bookmarkable and linkable — useful for pointing a colleague at "what a customer searching this actually sees" — and the form works without JavaScript.
And the scope is strict: it reaches published, public articles in your help centre and nothing else. No query can surface a draft or an internal article, however it is phrased. If you cannot find something you know you wrote, check its editorial state before you doubt the search.
Queries longer than 200 characters are refused rather than truncated.
Finding your own articles
Staff-side, the help-centre admin has its own filter over titles and text, and that one does see drafts and internal articles — it is the authoring view, not the customer's. Use it when you are looking for something to edit rather than something to link to.
The small pickers
Plenty of places offer a search box that only filters what is already on screen: assigning a ticket ("search agents or teams"), transferring a conversation ("search people and squads"), linking a conversation to a ticket ("search by subject, or paste a ticket id"), choosing a customer in a filter, picking a canned response.
These are pickers. They are fast and they are narrow, and none of them is a way to search the workspace — the list they filter is the list they were given.
Which box to use
- Looking for a screen? The command palette.
- Looking for a ticket? The inbox — filter, then search.
- Looking for a person? The customers list.
- Wondering what a customer can find? Your public help centre's search.
- Looking for an article to edit? The help-centre admin filter.