Helpdesk overview and ticket lifecycle

Admin › Tickets › Overview is the first stop for schoolHelpdesk. The top half tells you whether the parts tickets depend on are working. The bottom half sets the rules for closing and reopening tickets.

Anyone who can open Admin can open this page. Changing the ticket lifecycle needs Manage helpdesk settings (tickets_admin.manage); without it you can see the settings, but they and Save lifecycle are grayed out.

Readiness checks#

Under Operational readiness, a bar shows the Overall state. It's the worst state of the four checks, so one problem check makes the whole bar show that problem. Refresh reads everything again.

Each check is a section with its state beside its name. Checks that are Ready start closed, so the ones that need attention are the ones open; select a check's name to open or close it. Each shows one of these states:

• Ready. Working, and a check proved it.
• Provisioning. Set up, but nothing has proved it works yet. Run its check.
• Not configured. Not set up.
• Degraded. Partly working. Read the reason under its name.
• Error. The last check failed.

A check also shows why it's in that state, a Next: hint when there's something to do, the details it checked, and when it was last checked ("No backend check recorded" if never). Run check tests it now. Open goes to where you fix it.

The four checks:

• Workspace URL. Your account's web address, like yourdistrict.theschoolos.com. Run check looks the name up and makes sure the sign-in page answers over HTTPS. If it's missing, set one in Admin › Account › Account Settings under Vanity URL; Open takes you there. If it's set but failing, contact schoolOS support.
• Email channel. Whether email to your support address can become tickets. Email is set up by schoolOS, so the check shows its status and the emails accepted and rejected in the last 24 hours, not the setup behind it. Run check checks it again. It never sends an email. If requests emailed to your helpdesk aren't arriving, contact schoolOS support. To see your address or change it, go to Admin › Tickets › General.
• SLA. How many open tickets have an SLA target, how many are at risk or breached, and whether the SLA clock has run in the last 15 minutes. It has no Run check. If it says some open tickets have no target, fill in the missing rows in Admin › Tickets › SLAs.
• AI triage. Whether AI can suggest a priority, department, type and so on for new tickets. Run check sends a sample ticket ("Student Chromebook cannot connect to Wi-Fi") through triage and records the result. Nothing is created or changed. If AI triage is off, turn it on in Admin › Account › AI Features.

Open operational reports, at the bottom of the page, opens the helpdesk reports.

Ticket lifecycle#

These settings apply to every ticket in your account. The Ticket lifecycle section starts closed and shows what it's set to, like Reopens for 7 days; select its name to open it. Change them, then select Save lifecycle. You need Manage helpdesk settings.

• Require resolution summary. Off by default. When on, agents must write what fixed the problem before they set a ticket to a solved or closed status. The ticket asks for it in the close dialog, and schoolOS refuses the change without it, including bulk changes. Turn it on if you report on how problems were fixed. Leave it off if closing should stay one click.
• Require closure code. Off by default. When on, agents must also type a short reason, like "Resolved", "Duplicate" or "No response" (up to 100 characters). It's free text, not a list, so the same reason can be written different ways. Turn it on only if your team agrees on the words to use.
• Reopen window (days). How long a solved ticket can be reopened. See below.
• Optional pending-ticket cleanup (days). Blank by default, which means off. When set (1 to 365), a ticket in a pending status that nobody has updated for that many days is closed automatically. The timeline says "Automatically closed after the configured pending period". Any update to the ticket, even an internal note, restarts the count. Use it when tickets waiting on a reply tend to pile up. Leave it blank if a pending ticket should wait as long as it takes.

Which should I choose?#

| Setting | Leave the default when | Change it when | | --- | --- | --- | | Require resolution summary | Closing should stay one click, and nobody reads how tickets were fixed. | You report on how problems were fixed, or want the next agent to find the fix on the ticket. | | Require closure code | Your team hasn't agreed on a short list of reasons. Free text with no agreed words makes a messy report. | Your team uses a fixed handful of reasons and you report on them, like how many tickets were duplicates. | | Reopen window (5 days) | Requesters usually reply within a school week. | Requesters are slow to answer, like staff over a long break: go longer. Or your queue fills with solved tickets nobody comes back to: go shorter. | | Pending-ticket cleanup (off) | Pending tickets are waiting on things that take a long time, like parts or vendors. | Pending tickets are mostly waiting on a requester who never answers. |

For example, a district IT team turns on Require resolution summary and leaves Require closure code off, sets the Reopen window to 10 days so tickets solved on the Friday before a break can still be reopened when staff return, and sets Pending-ticket cleanup to 21 days so tickets waiting on a teacher's reply don't sit forever.

Reopen window#

When a ticket is set to a solved status, the window starts. The default is 5 days; you can set 0 to 365.

• During the window, the ticket can be reopened and worked again.
• When the window ends, schoolOS closes the ticket for good within a few minutes. The timeline says "Automatically closed after the solved-ticket reopen window expired". After that, only people whose role has Reopen closed tickets can reopen it. Everyone else gets "The configured reopen window has expired".
• 0 closes solved tickets at the next check, a few minutes later.

A short window keeps the queue clean. A longer one gives requesters time to say "it's still broken" on the same ticket instead of opening a new one.

The lifecycle graph itself is fixed. See how statuses move.