Skip to content

The assistant and AI features

Four things use a language model, and one connector supplies all of them. The connector you choose decides where your ticket text goes.

The assistant. The orb at the bottom right of every staff page on a tablet or computer, and a button in the header on a phone, for anybody whose role holds client.view. A chat that understands plain language and runs real commands.

Ticket triage. New tickets are classified into a kind, a category, an impact and an urgency.

The AI read on a ticket. Two sentences saying what is wrong and where it stands, plus suggested next steps, loaded when you open the ticket.

A draft reply. Written into the composer for a technician to read, edit and send. A draft, never a send.

The MCP server. The same tool catalogue, for an AI client you connect.

All four work without a model, in reduced form. None of them stops working when the model is unavailable.

Where it runs Who pays Where ticket text goes
A local model Your configured Ollama server Your school supplies the hardware To that server
Your own key Anthropic, or any OpenAI-compatible endpoint You, to them To that provider, or to your own GPU box
Vendor-hosted Our endpoint Us, within your plan’s allowance To DigitalOcean, on open-weights models it serves itself: gpt-oss-120b, NVIDIA Nemotron 3 Ultra and BGE-M3. DigitalOcean is the only AI sub-processor for it

A local model is available through the container deployment’s Ollama option. Native and source installations need a separately configured Ollama server and model. Local inference sends prompts to that configured server; other connectors can still make outbound requests. CPU-only operation is possible, with response time depending on the model and hardware.

Your own key is faster and billed to you. It also decides where student and staff ticket text is allowed to go, so each option is a separate connector.

Vendor-hosted is managed hosting only, on plans that include it. Each school’s managed deployment has its own server. Hosted inference avoids reserving that server’s memory for a local model. Eligible provisioning can configure vendor inference before the first sign-in. See plans for allowances and the overage rate.

Self-hosted deployments never receive vendor credentials.

The orb appears for roles holding client.view, which is the permission the assistant’s own people lookup already required, and which Owner, Technician and Read-only all hold. A custom role without it does not see the orb and is refused if it calls the endpoint directly.

One question is capped at 2,000 characters, as is each earlier turn the chat carries forward. Everything you send is read again by the model on each step it takes, so a pasted log file costs several times what it looks like.

  1. Click the orb, bottom right. The panel opens out of it with example prompts, and the orb becomes its close button. On a phone, use the assistant button in the header instead; the orb would sit over action bars and the keyboard.
  2. Type a question or command, or click a suggestion. Matching examples autocomplete as you type.
  3. Results come back as text, and often as a clickable table. Click a row to jump to that loan, device, person or submission.
  4. Follow-up chips suggest sensible next steps.

It remembers who you are talking about within a conversation, so “issue them a loan” works after looking somebody up.

It stays on the service desk. Ask it for trivia or arithmetic and it will point you back at what it can do.

Published knowledge answers include links to their source articles. Native ticket summaries and reply drafts help prepare work; review the result before using it. A proposed change presents the recorded action for approval. Reviews expire and cannot be reused for a different action; request a new review if the record or your permissions have changed.

An administrator can configure a separate advisory connection for selected staff with both client.view and assistant.agentforce.use. The connection stays disabled until its advisory configuration is verified. This pilot still needs live Salesforce sandbox validation before wider use.

Choose the provider in the assistant before typing. Messages sent in Salesforce mode go to Salesforce; previous native chats and page context are not forwarded. Salesforce’s configured execution identity determines remote access, so it must be appropriate for every staff member granted the pilot permission. Switching providers starts a separate conversation. If an interrupted request pauses the conversation, check its outcome in Salesforce before repeating it.

Reports, submissions, stock, stocktake, costs, loans, people, monitors, printers and inductions each have their own prompt box, scoped to that screen. “How many last month” means repairs on the repairs page and stock counts on stocktake, so you do not have to say which.

The prompt box sits at the top of the page, under the page heading, with Send and, once there is an answer, Clear beside it. The person page has one too, scoped to that person.

From 0.21.0, on tickets, devices, people, loans, repairs, stock, AV rooms, printers and monitors, a request such as unassigned tickets, available iPads, inactive students, low stock, offline rooms or printers with alerts sets that page’s own filters rather than answering with a short list. The applied values appear as buttons you can switch off one at a time or clear together, and the page’s normal controls show the same filters. Filtering changes no records and never shows more than you could already see.

A request the page cannot filter exactly, such as one with a qualifier the page has no filter for, conflicting values or an analytical question, is answered by the assistant instead, rather than silently dropping part of what you asked. The floating assistant can filter the page you are on in the same way.

  • How many laptops are on loan?
  • Who has loan #1?
  • Available iPads
  • Overdue repairs
  • Open repairs for Riley Brooks
  • Unassigned submissions
  • Show me open tickets
  • Unassigned tickets
  • How much did we spend this year?
  • Issue a loan to Riley Brooks
  • Create a damaged display repair for Riley Brooks with a loan

Exact wording is not required with a model connected. Without one, a built-in command engine handles the recognised phrasings above, offline and free.

Tickets and repairs are two queues, and the assistant keeps them apart. Tickets means the service desk - access requests, accounts, software, network. Repairs and submissions mean work on a device. Ask for tickets and you get the ticket queue, not the bench. On a school without the Tickets module the word still means repairs, because there is no other queue to read.

It acts as well as reporting. Before anything that changes data it shows a confirmation prompt.

Actions respect your permissions, and every one is audited. There is no path through the assistant to something your role forbids - including reaching the chat itself, which needs client.view.

New tickets are classified in two passes, in this order.

Rules first. Deterministic, explainable, and they run with no model configured. You can edit them.

Then the model, where one is connected, asked to improve on the rules rather than to start from nothing.

The model’s answer is accepted only where it picks from lists your institution uses. Anything else is dropped, so an invented category never reaches your reports.

Everything it decides is overwritable. The moment somebody edits one of those fields the ticket is marked as theirs and is never re-classified.

On the ticket page: a two-sentence summary of what is wrong and where it stands, and what the desk would do next.

It loads when the page opens rather than waiting behind a button, because on the bundled model the wait is real and it should not happen in front of somebody who has just clicked.

With no model configured the panel says so instead of showing an empty box.

Also on the ticket page. The model writes a reply into the composer.

It is a draft and never a send. A technician reads it, edits it and sends it, the same as anything else they type. Nothing reaches the person who raised the ticket without somebody deciding it should.

Exceed your permissions. The model chooses among commands; the permission checks run regardless.

Act without confirming. Anything that writes shows a prompt.

Answer general questions. It works on your desk data and nothing else.

Invent a category or a status. Triage answers outside your own configured lists are dropped.

The bundled model costs nothing beyond the hardware.

Your own key is billed by your provider. The work is small: a triage or a summary is a few thousand tokens in and a few hundred out. A desk triaging around three hundred tickets a month lands between five hundred and fifteen hundred calls.

Vendor-hosted is included up to your plan’s monthly allowance, then $25 per 1,000 calls. Only vendor-hosted calls are counted. Your own key and the bundled model are yours, and are not metered.

Past the allowance the vendor model steps aside and AI falls back to your own model or key, or to the no-model path. Nothing stops working.

Work is routed by whether somebody is waiting. Background triage runs on the slower local model; a summary somebody is watching for goes to a faster one.