Views, filters and search

The inbox is the list of tickets you work from. It is a single list with a large set of filters applied to it, rather than a set of separate mailboxes, and everything you can do to narrow it down is a filter you can combine with any other.

Filtering

Filters fall into two groups.

Some accept several values at once: status, priority, source and tag. Within one of these, the values are combined with OR — asking for status open and status pending returns tickets that are either. Across different filters they are combined with AND, so open-or-pending and priority urgent means both conditions must hold. This is the behaviour you want in practice: it lets you build "everything still live, at high priority, that came in by email" without any special syntax.

The rest take a single value:

• Assignee — a specific person, or one of two special values: me, for your own tickets, and unassigned, for tickets nobody has picked up.
• Team — a specific team, or none for tickets not routed to any team.
• Customer — everything from one customer.
• Overdue — tickets past an SLA deadline.
• Snoozed — tickets currently snoozed.
• Created by me and mentions me — your own tickets by authorship, and tickets where you have been mentioned.
• AI state — narrows to tickets by how an AI agent left them, distinguishing resolved, unresolved and answered conversations, and live chats.

An important default: if you do not filter by status at all, merged and deleted tickets are left out. They are not part of the working queue. If you genuinely need to see them — to check where a merged ticket went, for instance — name the status explicitly and they will be returned.

If you pass a value that is not a real status, priority, source or sort option, Auralis rejects the request and tells you which value it did not recognise, rather than quietly ignoring it and showing you a list that is wrong in a way you cannot see.

Sorting

There are six sort orders:

• Last activity — most recently updated first. This is the default.
• Priority then activity — urgent, high, normal, low, and within each band the most recently updated first.
• Priority — strictly by priority band.
• Oldest — least recently updated first, for working a backlog from the bottom.
• SLA due — soonest deadline first, with tickets that have no deadline at the end. This is the order to work in when you are trying not to breach.
• Created — newest first by creation time rather than by activity.

One rule overrides all of them: a ticket with a live chat session waiting sorts to the top regardless of which order you have chosen. Somebody is sitting there typing, so no sort option will bury them.

Searching

Search is part of the inbox rather than a separate screen. Enter a search term and it is applied as another filter, which means you can search within whatever you have already narrowed down — searching for "refund" while filtered to one team and to open tickets searches only those.

The search covers the ticket subject and description, the customer's name and email address, and the bodies of the messages on the ticket. It is a text search, so it finds tickets containing the words you typed rather than answering questions about them.

Counts

The inbox shows counts alongside the list, and there is one thing to know about them: the headline counts are deliberately not filtered. The per-status, per-source and navigation counts describe the whole workspace, not your current filter. This is intentional — the counts are there to tell you what is waiting elsewhere while you are looking at one slice, and a set of counts that only ever agreed with the list in front of you would be useless for that. The total alongside the results is the one that reflects your filters.

Counts of unread tickets and a count of SLA breaches are shown by the same mechanism.

Saved views

When a combination of filters turns out to be one you use every day, save it as a view. A saved view stores the filters and sort together under a name, so that "my urgent open tickets" or "unassigned in Billing" becomes one click instead of five. Views can be reordered so the ones you use most sit at the top of the list.

Any editor can create and edit saved views; deleting one requires an admin, since a view is shared furniture rather than a personal setting.

Working in bulk

When a filter has isolated a set of tickets that all need the same thing, you can act on them together rather than one at a time. Bulk actions apply the same change — a status move, a priority change, an assignment — across every ticket you have selected. The same transition rules apply to each ticket individually, so a bulk "solve" will move the tickets that are allowed to move and will not force the ones that are not.