Statuses, priorities and filters

This page is the vocabulary: what the states mean, what priority actually does, and how filters combine. It applies equally to the Inbox and to GET /v1/tickets, because both are the same query.

For the Inbox itself — the panes, the sidebar, saved views — see The Inbox.

Statuses

What can move where

The three live states — open, pending, on_hold — move freely between each other, and any of them can go to solved, closed or spam.

The terminal states have no legal moves at all. A solved ticket cannot be set back to open by an ordinary status change; the API reports its legal next states as an empty list. Getting a finished ticket back into the queue is a separate operation — see Merging, reopening and closing.

Priorities

urgent, high, normal, low.

Priority does two things, and neither is decoration:

1. It selects the SLA policy stamped on the ticket when it is created. See SLA policies.
2. It sorts the queue. The default ordering is priority first, then most recent activity within each band, then id. That ordering is stable, which is what makes paging through a moving queue return each ticket once rather than skipping and repeating.

In the list, only high and urgent get a coloured pill. That is deliberate: a hundred rows of normal would bury the two that matter.

How filters combine

Filters combine with AND. Values within one filter combine with OR.

So selecting open, pending and urgent means (open or pending) and urgent — not three separate queues, and not an empty intersection.

curl -sk -G https://api.localhost/v1/tickets \
  -H "Authorization: Bearer $AURALIS_API_KEY" \
  -d status=open -d status=pending \
  -d priority=urgent

Two filters take sentinels rather than ids:

• assignee accepts a user id, me, or unassigned.
• team_id accepts a team id or none.

Counts describe different things on purpose

• total counts the tickets your current filters matched.
• The counts on the rows and channel chips are unfiltered, workspace-wide.

That is not an inconsistency. A chip has to tell you what selecting it would give you; if it counted only within your current filter, every chip would read zero as soon as you narrowed the queue.

An unknown filter value is an error

?status=opne does not return an empty list. It returns 400 invalid_status, naming the value.

This is worth understanding because the alternative is worse: an empty result reads as "no tickets", which is a far more expensive misunderstanding than a refused request. The same applies to priority, source and sort.

Saved views

A saved view is a set of filters under a name. It can be private to you or shared with the workspace.

A view stores status, priority, assignee scope, overdue and the search term. It does not store the channel filter — if one is active when you save, the dialog tells you it will not be part of the view rather than dropping it silently.

Applying a view needs no particular role. Saving one needs editor; deleting one needs admin.

Opening a ticket by hand

New ticket takes a subject, an optional description and a priority, and records the ticket with source manual.

Use it for work that reached you some other way — a phone call, a corridor conversation. Customer traffic should arrive through a connected channel instead, so that replies thread back correctly. See Channels.

Next

• The Inbox — the screen these rules are applied on.
• Replying
• Assignment and teams