Ticket statuses and priorities

A ticket's status is the single most important field on it. It answers the question "does this still need somebody?" and it drives what the inbox shows first, which SLA clocks are running, and what the reporting counts.

The statuses

There are six statuses you can set:

• Open — the ticket needs work from your team. This is where every new ticket starts.
• Pending — you have replied and you are waiting on the customer. Use this when the ball is in their court, not yours.
• On hold — the ticket is blocked on something inside your own organisation: a fix from engineering, a decision from finance, a part on order. The distinction from pending matters when you are trying to work out whether a slow queue is your fault or your customers'.
• Solved — the work is finished. Solving a ticket stamps the time it was solved, and the first time a ticket is solved it also records a customer-satisfaction request.
• Closed — the ticket is finished and settled.
• Spam — the ticket was not a genuine request.

Two further statuses, merged and deleted, exist on tickets but cannot be set by hand. A ticket becomes merged as a result of merging it into another ticket, and deleted through deletion. You will only encounter them as the state of a ticket that something else has already moved.

How tickets move between statuses

Auralis enforces the allowed moves rather than letting any status become any other.

Open, pending and on hold are freely interchangeable. From any one of them you can move to either of the other two, or to solved, closed or spam. This is the ordinary working part of the lifecycle and nothing there is restricted.

Solved, closed and spam are terminal. Once a ticket reaches one of them it has no onward transitions at all, and an attempt to change its status directly will be refused.

That last rule is the one that catches people out, so it has a deliberate escape hatch: reopening. Reopening is a separate action, not a status change, and it is the only way out of a finished state. It works on solved and closed tickets — attempting to reopen a ticket in any other state is refused with a message saying so. Reopening records the time it happened, which is what makes reopen rate a measurable thing rather than an anecdote.

Because the rules are enforced centrally, every ticket tells you what it will accept. A ticket carries its own list of legal next states, and the interface uses that list rather than guessing, which is why the status control sometimes offers fewer options than you expect. If an option is missing, it is missing because the ticket is in a state that does not allow it.

Setting a status to the value it already holds is treated as a no-op rather than an error, so re-applying a macro or re-saving a ticket will not produce spurious history.

Priorities

Priority is a separate field with four values: low, normal, high and urgent. New tickets are normal unless something sets otherwise.

Priority does two things. It orders the queue — several of the inbox sort options put urgent work above the rest — and it selects the SLA policy that applies, because SLA targets in Auralis are defined per priority.

That second effect is worth understanding before you change a priority in bulk. Changing a ticket's priority re-stamps its SLA deadlines from the moment of the change, using the targets attached to the new priority. Both the first-response deadline and the resolution deadline are recalculated. Raising the priority of an old ticket therefore does not instantly make it overdue against the stricter target, and lowering the priority of a ticket that is about to breach will give it a fresh, later deadline. Neither behaviour is wrong, but both surprise people who assumed deadlines were fixed at creation.

Where a ticket came from

Every ticket also records a source, which is how it arrived rather than how it is going. Sources include email, the web widget, a contact form, phone, voicemail, SMS, WhatsApp, Slack, Microsoft Teams, a handoff from an AI agent, the API, a migration from a previous helpdesk, and manual for a ticket an agent typed in.

Source is set when the ticket is created and describes its origin permanently; it is not something you change as the conversation moves between channels. It is most useful as a filter and as a reporting dimension — the inbox keeps per-source counts so you can see at a glance where your volume is actually coming from.