How tickets are routed

Every new ticket needs a department, a team, a person, a priority and a type. schoolOS fills them in a fixed order of steps. Each step fills what's still empty, and can replace a value a weaker step chose, but never one a stronger step chose.

You set most of it up on the Routing tab of Admin › Tickets › Topics & Routing, which lays the steps out in the same order. Accounts that route by departments and topics use the rules under Advanced on that tab instead of intake rules, in the same place in the order; see route requests with departments and topics.

Who wins#

From strongest to weakest:

1. A person. Whatever someone chose when they filed or changed the ticket. Nothing automatic replaces it. If a person clears a field on purpose, it stays empty.
2. How it came in. The address it was sent to, the portal's department, or a schoolAgent chat route.
3. A routing rule. The exceptions you set in Rules.
4. The topic. The topic's route: its team and priority, set on the topic or a topic above it.
5. The team's assignment. The team's method picks a person.
6. The location's team. A team that covers the ticket's location and takes new tickets from there.
7. AI triage. AI's guesses for priority, department, tags and device.
8. The default. The department's default priority, and its default team.

So a topic's priority replaces AI's guess, but not a priority a rule set. A rule's team replaces nothing a person picked.

The type has its own, shorter order: a person's choice, then AI triage's, then the topic's default type. See Ticket types.

Step by step#

For a new ticket:

1. It arrives. The channel may set the department, and sometimes a topic, team, person or priority. Mail to a team's own address goes straight to that team.
2. Rules, first pass. The first rule that matches, in the order set on the Routing tab of Admin › Tickets › Topics & Routing, fills what's still empty. It can set the department here, if nobody chose one. A rule's priority is skipped if that priority has been turned off.
3. Defaults. The ticket starts in the department's New status and default priority.
4. AI triage, if it's on in Admin › Account › AI Features. It suggests the priority, department, type, tags and device where nothing stronger decided them, and matches a topic if it's sure enough.
5. Missing details. If the topic has required fields, schoolOS reads the answers from what the requester wrote, and asks them once for anything missing.
6. The topic's type fills the type if neither a person nor AI triage set one.
7. Rules, second pass. Now that the topic is known, a rule can match it. The department stays as it is. A rule sets the team only if the ticket has none, or is on the default team or the location's team.
8. The topic's route. If the ticket still has no team (or only the default team or the location's team), the topic's team takes it. The topic's priority replaces AI's or the default.
9. The location's team. If no rule or topic chose a team, a team in the ticket's department that covers its location, with New tickets from these locations come to this team on, takes it. If several do, the one covering the fewest locations wins, then the name A to Z.
10. The default team. A ticket that still has no team goes to the department's default team, so none are left without an owner.
11. The team picks a person, if the ticket has nobody and the team's method isn't Manual. Members who handle the topic go first. Take turns picks the member assigned one of the team's tickets longest ago. If nobody can be picked, it waits in the team's queue.
12. SLA clocks start from the final priority and topic, each target on its own. See SLA targets.

Email tickets wait between steps 6 and 7 when the AI assistant is about to answer. If it answers, nobody needs to be assigned yet. If it hands off or can't answer, routing finishes then. The requester's acknowledgment email goes out after triage, so it can name the final department and ticket number.

If any step fails, the ticket still exists where it was filed. Routing never blocks a ticket being created.

An example#

A teacher at Lincoln Elementary emails the IT address: "The projector in room 12 won't turn on and I have a lesson at 10." Your account has one rule (tickets from the high school go to its own tech team), topic routes, and AI triage on.

1. It arrives by email at the IT department's address, so the department is IT.
2. The rule is for the high school, so it doesn't match.
3. It starts in New, at IT's default priority, Medium.
4. AI triage raises the priority to High (a class is affected), calls it an Issue, and matches the topic "Classroom technology › Projector or display".
5. The topic has no required fields, so nothing is asked.
6. AI already set the type, so the topic's default type isn't needed.
7. The rule still doesn't match.
8. The topic's route sends it to the Classroom tech team. The topic leaves priority to triage, so High stays.
9. It has a team, so the location's team isn't needed.
10. It has a team, so the default team isn't needed.
11. Classroom tech uses Take turns, so it goes to the member whose last ticket from the team is oldest.
12. The SLA clocks start from High: the targets "Classroom technology" sets for High, or IT's default targets if it sets none.

Ask Otto why the ticket is where it is, and it says: Department, How it came in; Team, Topic (Projector or display); Assignee, Team's assignment (takes turns); Priority, AI triage; Type, AI triage.

Which should I choose?#

Rules, topics and teams covering locations can all send tickets to a team. Use each for what it knows best:

| Option | What it does | Choose it when | | --- | --- | --- | | A topic's route | Sends a subject to the team that does that work, wherever it is. | Specialists own the work, like Records requests, network outages or HVAC. | | The location's team | Sends what's filed at a school to the team that covers it. | Generalists look after places, like "Zone 1 covers five schools" and its techs fix whatever breaks there. | | A routing rule | An exception you spell out, checked before topics and locations. | One case doesn't fit, like the high school's tickets going to its own tech team. |

For example, a district with 12 schools splits them into three zones, each with a team covering its schools and taking their new tickets. A projector ticket from a Zone 1 school goes to the Zone 1 team, while a records request from the same school still goes to the private Records team, because its topic routes it there first. When Lincoln Elementary moves to Zone 2, move it on the teams' Coverage, and new tickets from Lincoln go to Zone 2.

Why is this here?#

Every ticket keeps a trail: for its department, team, assignee, priority and type, which step decided it and why. The step is one of A person, How it came in, Routing rule, Topic, Team's assignment, Location's team, AI triage or Default, with the reason (a rule's sentence, the topic's name, the team's method).

The ticket's timeline records each automatic change and why it happened, and Otto answers "Why was ticket #1234 sent to Tier 2?" from the same trail.

To check a change before it affects real tickets, use Test routing.

When a ticket changes later#

• When someone edits a ticket, the rules are checked again. A rule can still change a field that was set automatically, but never one a person set.
• When the topic or team changes, the new topic's route and the team's method fill what's still empty, unless the same change set or cleared the assignee on purpose.
• Changes from routing don't start workflows. schoolOS tells integrations, but "On a change" workflows only run for changes people make.