Tickets

/tickets, and /tickets/<id> for one. Needs module.tickets.

The service desk queue for everything that is not a device repair: faults, requests and questions.

0.12.0-rc.3 department beta preview

Optional Facilities, Administration and other desks add department filters, service questions, locations and explicit transfers to this workflow. See working across departments and the administrator guide for availability and access.

Working on a ticket

From 0.14.4, ticket detail has four views:

View	What you will find
Activity	Original report, submitted service answers, AI summary, conversation and reply composer
Work	Checklist, assigned subtasks, evidence, dependencies, templates, approvals, security approvals and time tracking
Context	Requester information, linked devices/repairs/answers, labels, parent/child/related tickets and watchers
Files	Attachments from messages you can access, with internal files labelled

Pending approvals and required work or child tickets that block completion appear above the tabs. Switching views preserves unsaved inputs. Arrow keys move between tabs; following a link to a tool opens the containing view.

Above the tabs, compact chips show the ticket at a glance: Time logged, against the estimate when there is one, your timer, Watchers, and Checklist progress when the ticket has a checklist. Each chip opens its section. For people who can update the ticket, Time has Add beside it and Watchers has Watch or Unwatch. From 0.17.1 there is no Files chip; the Files tab lists the attachments, with its count on the tab.

Time

From 0.17.1, with the Time tracking module on, you can run a timer on a ticket, log time with a reply or note, set an estimate and see every entry on the Work tab. The timer can start by itself when you begin writing. Resolving a ticket you have logged no time on can ask you to add some first. See time tracking for all of it.

ThreatLocker requests

When a ThreatLocker request on the ticket is waiting, it appears at the top of the ticket at every screen width, naming who asked, on which computer and for which file. People with device.manage can Approve or Deny it there. Anybody else sees that it is waiting on somebody who can manage devices. After a decision, the strip stays as a confirmation so you can see what you just did.

Connected systems

A Connected systems card in the ticket details lists what each connected system knows about this ticket: the ThreatLocker request, the device’s management state and last check-in, the requester’s directory account, monitoring for any services the ticket mentions, and links to the requester’s other systems. Choose a row to jump to its detail. A system with nothing to say about this ticket is left out.

The requester’s name links to their person page.

On desktop, Ticket details keeps requester, status, priority, assignee, queue and SLA information alongside the workspace. Due-date editing is directly below the due value, and Classification & dates holds the additional fields. On phones, press Ticket details to open the same controls. With time tracking on, Ticket details also holds the ticket’s Estimate.

Use Reply to reach the composer in a long conversation, and Add on the Time chip to open the Log time form. Actions contains configured school actions, history, department transfer and merge. Available controls follow your permissions. Check your installed version against the release notes.

If you already run Zendesk or Web Help Desk for this, switch the module off and connect that instead. Two queues means work gets lost between them.

A ticket carries

Number	Sequential, and what people quote
Subject and body	What was asked
Requester	Who asked, whether or not they have an account
Category	What it is about
Queue	Which team owns it
Assignee	Which person owns it
Status	Configured on the workflow page
Priority	Drives SLA targets
Conversation	Public replies and internal notes

Public replies against internal notes

The distinction that matters most.

A public reply goes to the requester by email and appears in their thread.

An internal note is for the desk. It never sends, and it is gated behind the separate ticket.internal permission.

An internal note is where somebody writes “third time this term, escalate” or “her mother rang, do not put this in writing”. Separating the permission means a school can hand a casual or a student helper the queue without handing them that.

Know which one you are writing in. The interface makes it clear, and it is worth saying out loud to a new starter anyway.

Choose Reply to requester or Internal note in the composer. A failed send keeps your draft. If the message was saved but an attachment failed, use Retry attachments to send the remaining files without creating a duplicate message.

Suggested actions

A card on the ticket offers things you can do in one click, each with the fact behind it. Reply that the printer fault is known, because monitoring is reporting it. Issue a laptop bag, because there are eleven. Open the directory panel for an access request, carrying the ticket with it.

These come from rules and live lookups, not from a model, so they are instant and never a guess. They offer; they do not act.

What the AI does here

With an AI connector configured, three things happen on tickets. All three work in reduced form without a model.

Triage. A new ticket is classified into a kind, a category, an impact and an urgency. Your own rules run first and always; the model is asked to improve on them. Its answer is accepted only where it picks from lists you already use, so it cannot invent a category that turns up as a heading in your reports.

The AI read. A visible AI summary in Activity explains what is wrong and where it stands. It loads when you open the ticket; Refresh requests another read. Expand Suggested next steps to see advice and permitted actions.

A draft reply, written into the composer. A draft and never a send.

Anything the AI decides is overwritable, and the moment somebody edits one of those fields the ticket is marked as theirs and is never re-classified.

Canned responses

Saved replies for the answers you send repeatedly, configured under ticket settings.

Once you have sent the same canned response forty times, put the answer on the public help centre.

Reopening

A closed ticket can be reopened within a window you configure. Past that, a new ticket is raised instead.

The window matters for your reporting. Too short and one unresolved problem becomes four tickets. Too long and something from last term comes back to life on somebody who has forgotten it.

Merging

Duplicate tickets can be merged, which happens most often when somebody emails and then walks up to the desk. The merged ticket keeps the conversation from both.

Service levels

Tickets are covered by SLA targets per priority, the same as submissions. The clock reads which statuses mean the desk is not the one being waited on, so a ticket parked pending a customer response stops accruing.

Raising a submission from a ticket

Work that starts as a question and turns out to be a device problem should become a submission, because that is where the device, the repair type, the coverage and the cost live.

Directory actions work the other way: an account change in the Accounts view of People can be attached to an existing ticket or raise a new one, so “please give Sarah access to Tom’s mailbox” becomes an auditable record.

Permissions

Permission	Allows
ticket.view	See tickets
ticket.create	Raise one
ticket.update	Change status, queue, assignment
ticket.comment	Reply publicly
ticket.internal	Read and write internal notes
ticket.close	Close one

Time tracking uses these too, with workflow.manage for changing somebody else’s time entries. See time tracking.

Configuration

Categories, queues, canned responses, the reopen window and time tracking are under ticket settings. Statuses and priorities are on the workflow page alongside submission ones.