Skip to main content
Page guide

Ticket topics

The subjects a department's tickets are about, in one tree as deep as you need. AI triage reads each description to give new tickets a topic, and a topic's type, team, SLA and fields pass down to its subtopics.

The Topics tab of Admin › Tickets › Topics & Routing holds what a department's tickets are about, as one tree: "Devices › Chromebooks › Broken screen", "Accounts & access › Password reset". Topics do three jobs:

  • AI triage gives each new ticket a topic, by reading the topic descriptions.
  • A topic decides how its tickets are handled: their type, team, priority and SLA targets. This is the normal way tickets find their team. See how tickets are routed.
  • A topic asks for what it needs. Its fields show on its tickets. The ones marked Required are asked of the requester before the ticket is sent, and an agent who moves a ticket to the topic fills them in first. See Fields.

You need Manage helpdesk settings to open this tab. Each department has its own tree. When you have more than one department, pick one with Department at the top of the page. With departments turned off, your account has one built-in department, and the tab works in it without asking.

The Topics tab: the topic tree on the left, and the selected topic with its type, team, fields and SLA on the right
The Topics tab: the topic tree on the left, and the selected topic with its type, team, fields and SLA on the right

schoolOS administrators choose Account before managing Topics & Routing. The department choices, topics, fields, routing, and triage results come from that account. Switching accounts clears open forms and the previous department selection; save your changes first.

Topics, routing, fields and triage#

Admin › Tickets › Topics & Routing (Topics & Routing) has four tabs:

  • Topics: the tree, and each topic's settings. This article.
  • Routing: where requests go. With departments and topics, every department, its topics and what happens when nothing fits, the same editor as schoolAgent's Routing tab (route requests with departments and topics); on an account that still runs intake rules, those rules (ticket routing).
  • Fields: the questions the ticket form asks. See Ticket fields.
  • How triage is doing: how often people keep the topic AI triage picks. See below.

Department, at the top, applies to every tab but Routing, which covers every department. The tab, the department and the open topic are part of the page address, so a bookmark or a shared link opens the same view. You see the tabs your role can open: Fields with View ticket fields, the others with Manage helpdesk settings. The old Ticket Topics, Ticket Types, Ticket Fields and Ticket Routing pages, and Intake's old Intake rules tab, open their tab here; Ticket Types opens Topics, because types replaced types.

Get started#

A department with no topics shows No topics for … yet, with two choices:

  • Add starter topics. A set written for K-12 schools: for IT, topics like Accounts & access, Devices, Classroom technology, Network & internet, Printing and Software & apps; for Facilities, Heating & cooling, Plumbing, Electrical & lighting, Doors, locks & keys, Custodial, Grounds, Furniture & moves and Safety hazard. Each comes with subtopics, descriptions and a type. Read the descriptions and make them yours. Departments you add yourself get no starters.
  • New topic. Start from scratch.

Later, Add any missing starter topics, under the tree, adds starters you don't have without touching the ones you do.

The topic tree#

The left side lists the department's topics, each subtopic indented under its parent, as deep as you need. Each row shows:

  • The topic's type as a badge. A faded badge means the topic takes it from a topic above it.
  • How many subtopics it holds, at every level under it.

Search topics... finds topics by name and keeps the topics above each match, so you see where it sits. Collapse all and Expand all fold the tree; the arrow beside a topic folds just that one.

Select a topic to open it on the right.

Add, move and remove#

  • New topic, at the top of the page, adds a topic. Under Level, choose Main topic (at the top of the list) or Subtopic, then pick the topic it goes Under. Any topic works: under a main topic it's a subtopic, under a subtopic a sub-subtopic, and so on. The line underneath shows where it lands, like "Devices › Broken screen › Cracked glass · Sub-subtopic". Then pick its Type (or the same as the topic above).
  • + Subtopic, on an open topic, opens New topic already under it.
  • Move puts a topic, with everything under it, somewhere else: Make it a main topic, or Move under a topic and pick one at any level. You can also drag a topic in the tree onto another one, or onto Drop here to make it a top-level topic. A topic can't move under itself or one of its own subtopics.
  • … › Rename changes its name everywhere, including tickets that already have it.
  • … › Remove removes the topic and everything under it. Tickets that already have one keep it; triage just stops using it.

A topic's page#

The right side shows the open topic: where it sits (select a topic in the path to open it), its name, and each setting its tickets get.

Settings pass down#

A topic's type, team, priority, fields, SLA and privacy pass down to its subtopics until one sets its own. Next to each setting, the page says where it comes from:

  • Inherited from Devices means a topic above sets it. Select Override to set this topic's own.
  • Set here means this topic sets it. Select Use Devices' to go back to the one above.
  • From IT's default means no topic above sets it, so the department's default applies.

Set things as high in the tree as they're true. Put the team on "Devices" and leave its subtopics inheriting it; give "Devices › Interactive display" its own team only when different people do that work. One change on "Devices" then moves them all.

Description#

What belongs here, and what doesn't. AI triage reads this, so it's what makes matching work. It saves when you click away. For example: "Forgot a password, password expired, or locked out after too many attempts. Not sign-in codes; see Multi-factor sign-in." A topic without a description is matched on its name alone.

Type#

Four cards: Issue, Outage, Question and Request. Pick the type most of this topic's tickets are. A ticket that gets this topic takes its type, unless AI triage or a person already set one. See Ticket types.

When a ticket gets this topic#

Under Team:

  • Send to team. The team its tickets go to, or the same as the topic above. With no team set here or above, the topic doesn't move tickets: one that already has a team keeps it, and one with none goes to the department's default team. With no default team, it waits in the department's queue.
  • Priority. Sets the ticket's priority, or the same as the topic above. At the top it's Leave it to triage. Set one only when the subject decides it: "Safety hazard › Gas smell" is always urgent; "Devices › Chromebook won't charge" could be one student or a whole cart, so leave it to triage.

A line under the choices says where these tickets go. The team's assignment method then picks a person or leaves the ticket in its queue.

A topic's route only fills what's still open. It never replaces a team or priority a person chose, and a routing rule wins over it.

Topics and outages#

A topic doesn't decide which product on your status page a ticket is about. schoolOS reads each new ticket for the products it names, whatever its topic or department, so PowerSchool reports filed under SIS access, Grades and general IT count together as one possible outage. To teach it the names your district uses ("PS", "SIS"), add other names to the product. Topics that used to pick a status product had their names added to it as other names, so nothing they caught is lost.

Fields#

Everything a ticket with this topic asks for, right under Team:

  • Location and Device. Turn one on and a ticket needs it before it's filed under this topic: Hardware can require the device, Facilities › Leak the building. The topics under it require it too, and show Required, from Hardware (change it on Hardware). A ticket filed under the topic in schoolOS without it is stopped with what's missing. schoolAgent's Create a ticket works out the topic from the chat and asks for the person's device before they can submit; someone with no device assigned describes it instead. A requester's ticket is filed for their own school. Talk to a person asks too, before passing the chat to a schoolAgent route that files tickets under the topic: "which device is this about?", with the person's devices to pick (see Must know before sending). With both off, nobody is asked.
  • This topic's own fields, each with its type and what it asks of a ticket: Required, Required to close or Optional. Select one to change it in the same dialog you add it with. Drag a field by its handle (or … › Move up / Move down) to change the order tickets show them in.
  • Fields from the topics above it, marked From Devices. Select the topic's name to open it and change them there.
  • On every topic: the fields every ticket has, whatever its topic. First the built-in ones (Subject, Requester, Description, Assigned Agent, Status, Priority, Type, Group, Due Date), then the department's own fields, each with what it asks. They're read-only here: Edit in Fields opens the Fields tab. Select On every topic to fold the list away; it stays folded for you next time.

Add a field

Select Add field, then:

  • Create a new field. The field dialog opens with Show on set to this topic, so the field shows on this topic's tickets and every topic under it.
  • Or pick one your department already has. The list is A to Z and searchable, and says where each field shows today, like "Shown on Printing". Tick Required on Broken screen to require it here, then select Add to topic. One field can be on several topics, so "Asset tag" can be Required on "Broken screen" and optional on "Printing", and its answers stay in one place for reports. Fields already on this topic, or on every ticket, aren't offered.

Until your account's database is updated for shared fields, Add field can only create a new field, and says so.

Required, Required to close, Optional

  • Required. The requester answers it before the ticket is sent, like "Which room?" for "Heating & cooling". Email, chat and the portal ask once for anything missing after triage picks the topic. An agent who moves a ticket to this topic fills it in first (see Change the topic). For a field on several topics, Required is set for each topic on its own.
  • Required to close. Nobody is asked up front; an agent can't solve or close the ticket while it's empty.
  • Neither: Optional.

AI triage, routing rules and new tickets never wait for a required field. A ticket that gets this topic without one shows Needs: Room number under its topic until someone fills it in.

Keep required fields to the one or two nobody can start without. Each is one more thing between a teacher and help.

Remove a field

… › Remove on a field that's only on this topic deletes it, after you confirm; it says how many tickets have a value in it, which goes with it. A field that's on other topics too says Also on 2 other topics, and … › Take off this topic takes it off just this one: it stays on the others, with every answer already given. To delete a shared field everywhere, use the Fields tab.

SLA#

The first response and resolution targets for each priority. A ticket gets the targets of the nearest topic that sets them: its own topic's, else the closest topic above it with some. A ticket with no topic, or whose topics set none, gets the department's default targets from Admin › Tickets › SLAs.

Select Override to give this topic its own targets. They start as copies of the ones it had; type a new time in any box, like 90 (minutes), 4h or 1d 4h. Times that differ from the topic above are highlighted. Use …'s goes back.

Changing a ticket's type never moves its SLA clocks.

Privacy#

Mark a topic Private for records requests, HR and legal matters: work that only a few people should see. Its tickets can then be found and opened only by:

  • the people, teams and roles on its access list,
  • each ticket's requester and assignee,
  • anyone let in on one ticket (Private in the ticket's header).

No role gets around it, whatever its reach. Add a role to the list and everyone who holds it is in; add a team and its members are, as they come and go.

Subtopics are private too, with the same list, until one says otherwise: Override on "HR › Training requests" can make it not private, or private with a list of its own. Select Set it on a topic that isn't private (or Change on one that is), switch on Private, add at least one person, team or role, and select Save. Tickets already under the topic become private at once.

A private ticket stays private, even if it moves to a topic that isn't: it stays open to the list that made it private. AI triage can make a ticket private by giving it a private topic, but nothing makes a private ticket ordinary again. Turning Private off keeps the tickets that are already private as they are.

Two settings decide how a private ticket's messages show (see The privacy screen), and pass down like the rest:

  • Hide messages by default. On (the default): every message and internal note is blurred until someone chooses to show it.
  • Re-hide after. How long a shown message stays readable before it blurs again: 1 minute, 5 minutes (the default), 15 minutes or Never.

For example, a district marks "HR" private with the HR team and the Superintendent role on its list. A complaint that triage files under "HR › Complaints" is private from the moment it arrives: the Tier 1 agents who can see every other ticket in the department don't see it in their list, their search or their reports.

Add these to new tickets#

Templates every new ticket with this topic gets, from every channel (the form, email, schoolAgent, the public helpdesk, a kiosk, bulk entry), never imported history or tickets that already exist. Any number of them, task templates and checklist templates alike, added in the order listed: each checklist as a task holding its steps, each task template as a task of its own.

  • Add a template opens a picker: search, and All, Tasks or Checklists. It offers the topic's department's templates and the ones shared by all departments. Each is marked Task or Checklist · N steps and says who it goes to, such as "Goes to Field techs, the ticket's assignee".
  • The arrows move one up or down; × removes it.
  • Manage templates opens the Templates page beside it.
  • A topic with none of its own takes the list of the nearest topic above it that has one, and says so. Add one to give a subtopic its own list.

What happens on the new ticket:

  • Approvals. A checklist with approvals holds the ticket in Awaiting approval (its SLA clock paused, not routed yet) until they're decided, then it goes to the topic's team. Task templates and checklists without approvals never make it wait.
  • Who gets each one. As the template says. Steps and tasks for The ticket's assignee or The ticket's team are filled in as soon as routing picks them. Nobody adds them by hand, so Whoever adds it leaves them for someone to pick up.
  • Due dates count from the day the ticket is created, in your account's time zone; a template with a key date counts from that day too.
  • Once each. Each template is added to a ticket once, however often the ticket is routed again.
  • Changing a ticket's topic later doesn't add the new topic's templates: they're for new tickets.

A template that belongs to another department can't be added; one a topic already had keeps working. Changing this list needs the same permission as editing topics.

Until your account's database is updated for it, a Request topic has a single Checklist here instead, which its subtopics inherit; Preview for a person… says who a requester's approvals would go to. See Approvals.

How AI picks a topic#

When a ticket arrives and AI triage is on, triage reads the ticket and the department's topics, and ranks them. It gives the ticket the most specific topic that fits: one with no subtopics. It reads each topic's description together with the descriptions of the topics above it.

It only sets a topic when it's sure enough (see How sure should triage be?). Otherwise the ticket gets no topic, and a person picks one. It also picks a type and notes whether the requester sounds upset.

Topic matching is part of AI triage. It's on unless someone turned AI triage, or its topic part, off in Admin › Account › AI Features.

Test it#

The Test it section, at the bottom of a topic's page, shows which topic triage would pick. Paste a ticket's text and select Test. Nothing is saved.

The result shows Triage would set and the topic, or Triage would leave the topic for a person with the closest match and how sure it was. Under it, the top topics with a bar for how likely each is, None of these, the reason, the requester's mood, and which AI model answered.

Test the tickets your team argues about. If two topics come out close, make their descriptions say how they differ.

How triage is doing#

The How triage is doing tab. Pick Last 30 days, Last 90 days or Last 365 days (90 to start).

A topic counts as kept when the ticket still has the topic triage gave it.

  • Topics kept. The share of triage's topics people left alone.
  • Left for a person. Tickets triage wasn't sure about, and how many people have sorted since.
  • Handed off. Tickets the AI assistant passed to a person, and why: asked for a person, upset, or not in knowledge.
  • By topic. For each topic, by its full path: how many times triage set it, how often it was kept, and what people most often changed it to. A topic kept less than 75% of the time is flagged. Topics with fewer than 5 picks aren't flagged yet.
  • By model. The same, by AI model.
  • Changed by people. The latest 25 tickets where someone changed triage's topic. Read a few: if the request really was about the other topic, say in both descriptions how they differ.

How sure should triage be?#

Three choices, set per department. Each shows what it would have done with the tickets people settled in the period you picked: how many would get a topic, and how many of those would be right.

| Choice | What it does | Choose it when | | --- | --- | --- | | Only when sure (80%) | Sets fewer topics; people rarely change them. | A wrong topic sends tickets to the wrong team, like Facilities work orders landing with IT. Someone sorts the rest by hand, so you need a person watching No topic. | | Balanced (60%) | The default. Most tickets get a topic. | You're starting out, or the numbers under the other two don't show a clear win. | | Most of the time (40%) | Sets more topics; people change more of them. | An unsorted ticket costs more than a wrong one: a small team with no one sorting, where a ticket with no topic waits on the default team. |

Read the numbers under each choice before you switch, like "75% get a topic · 97% right". For example, if Only when sure shows 75% get a topic and 97% right, and Balanced shows 92% and 89%, Balanced sorts about one ticket in six more, and gets a few more wrong. Pick Balanced if moving a ticket by hand is cheap; stay with Only when sure if a wrong team means a missed repair.

The How sure should triage be? choices, each with what it would have done
The How sure should triage be? choices, each with what it would have done

The choice applies to new tickets from then on.

Was this article helpful?

Updated October 26, 2026