General ticket settings

Admin › Tickets › General holds the settings that apply to every ticket in your account: how the reply box opens, how email becomes tickets, and how long personal information stays in them.

Anyone who can open Admin can open this page and see these settings. Changing them needs Manage helpdesk settings (tickets_admin.manage): the reply box, the Verify new senders switch, verifying or discarding a waiting sender, the auto-response and removing personal information. Without it the controls are grayed out and there's nothing to save. Support email isn't covered by it.

The AI switches for tickets aren't here. They're in Admin › Account › AI Features, and the page links there at the top.

Each part is a section that opens and closes from its name; closed, it shows what it's set to, like Collapsed (default) or On for 1 of 2 departments. The reply box, first, starts open and the rest start closed, and the page remembers what you left open. Each part saves in its own way:

• Reply box and the Verify new senders switch save the moment you change them.
• Auto-response saves with its own Save auto-response button.
• Remove personal information saves the moment you change it.
• Support email saves each address when you select Save next to it.

Reply box when a ticket is opened#

What agents see under the conversation when they open a ticket. Agents can still open or shrink the box on any ticket.

• Collapsed (default). A compact bar with Reply, Internal note and Update as until the agent selects Reply. Leaves the most room to read. Best when agents read more tickets than they answer.
• Always open. The box is ready to type in. It fills the space under the last reply: tall on a short conversation, short on a long one so the latest messages stay in view. It resizes as replies arrive, but never while an agent is typing or after they've resized it. Best when most tickets get a reply straight away.

Who an email is from#

Email to your support address is matched to one of your people by its address. Someone who isn't one of your people yet is added, by where they write from:

• At your district's own email domains, or a subdomain of one (students.yourdistrict.org): added as Staff. They're your own people that no sync has brought in yet, and a sync gives them their real role.
• At any other address, free email like gmail.com included: added as a Guest, someone from outside your district. A Guest sees only their own requests and can sign in only after confirming their address. They become one of your people, with their tickets, when you add, import or sync the same email. Who Guests are and what they can do.

A Guest's request is routed as one from The public, so a routing rule for staff doesn't catch a stranger's email. A new Staff sender's request is routed as one from Staff.

For example, a vendor at sunburstworkforce.com emails the support address for the first time, and the ticket is filed for them as a Guest. A teacher at yourdistrict.org who isn't synced yet emails too, and is added as Staff. If the vendor tries Continue with Google on your sign-in page, they see only their own ticket, and are asked to confirm their email first unless Google vouches for the address.

Verify new senders#

Off by default. When it's on and someone who isn't one of your people emails your support address, schoolOS holds the email and sends them a button to confirm their address. Once they confirm, the email becomes a ticket as usual, and they're added as a Guest who can sign in.

• People you've added, imported or synced never need to verify. Neither does anyone an agent has added to a ticket. Being added to a ticket lets their email through, but doesn't let a Guest sign in: only the person can confirm their own address.
• The link works for 3 days. Held email is kept for 14 days, then deleted.
• Each address gets at most one link a day, and at most 20 emails are held for it. More than that are dropped.
• Auto-replies and no-reply addresses never get a link.

Turn it on when spam or strangers' email is filling your queue. Leave it off if parents and the public should reach you by email without an extra step.

For example, an IT helpdesk that only staff and students email turns it on: they're all synced, so they never see a link, and a vendor's cold email waits in Waiting to verify instead of becoming a ticket. A Facilities department that takes requests from community groups renting a gym might leave it off, or turn it on and check Waiting to verify each morning.

When someone is waiting, Waiting to verify lists their address, how many emails are held, the latest subject and when it arrived. For each:

• Verify and create tickets. Trusts the address and turns their held email into tickets now.
• Discard. Deletes their held email.

These act straight away. If you turn verification off, new email isn't held, but anything already waiting stays until the sender verifies or you act on it.

Guest accounts#

On by default. Someone who isn't one of your people can make themselves a Guest on your district's own sign-in page, once Google or Microsoft confirms their email: they see You're new here, type their name, and select Continue as a guest. A Guest sees only their own requests. With it on, someone who confirms their email from a request is also offered Use my Google account (or Microsoft) and Set a password, so they can come back to follow it.

• It works only on your vanity URL. On app.theschoolos.com, schoolOS can't tell which district they mean, so it asks them to use your district's sign-in link.
• An email at your own domains never becomes a Guest. Those are your people, so they ask you for access instead (you approve it on the sign-up requests page).
• Turning it off doesn't touch the Guests you already have: they still sign in.

Leave it on if families and the public send you requests and should be able to follow them. Turn it off if only your own people should sign in: someone you don't know is told to ask you to add them.

For example, a district whose transportation office takes bus questions from parents leaves it on: a parent signs in with their Gmail on lincolnusd.theschoolos.com, continues as a guest, and sees every reply on their request. A district whose helpdesk is for staff only turns it off.

Forwarded email#

On by default. When an agent or admin gets an email that should be a ticket, they forward it to your support address, and the ticket is for the person who sent it:

• Requester. The person who sent the original. If they aren't one of your people yet, they're added, as anyone who emails in is.
• Description. The forwarded message, with its From, Date and Subject lines. "Fwd:" comes off the subject.
• What the forwarder wrote above the forwarded message goes on the ticket as an internal note, so the requester never reads it.
• Created by is the forwarder, and they follow the ticket.

schoolOS reads the sender from the forward itself, the way Gmail, Outlook and Apple Mail write it. When Outlook shows only a name, like "From: Jane Doe", it's matched to the one person with that name; if two people share it, or nobody has it, schoolOS doesn't guess.

To name the person yourself, start the forward with a line like requester: [email protected]. It wins over what the forward says.

When the sender can't be settled, the ticket is the forwarder's, as any email is, and its history says why. Change the requester on the ticket. That happens when:

• The forward has no From line schoolOS can read.
• It names someone without an address who isn't exactly one of your people.
• The original came from a no-reply address or one of your support addresses, like a schoolOS notification forwarded back in.
• Your email domain doesn't pass DMARC, so schoolOS can't confirm the forward came from your staff. Anyone can type a "From:" line into an email, so only a forward that provably came from an agent or admin is trusted. Ask whoever runs your email to set up DMARC.

Only agents and admins work this way. Anyone else who forwards an email to you opens a ticket as themselves.

The original sender gets your auto-response only if they're already one of your people, and the AI assistant doesn't answer forwarded tickets. That keeps a phishing email someone forwarded for you to look at from confirming to its sender that your address is read.

For example, a principal emails the technology director about a broken projector. The director forwards it to the support address with "Room 12, can someone look today?" above it. The ticket is the principal's, the director's line is an internal note, and the director follows the ticket.

Turn it off if your staff forward email to the helpdesk only to keep it for themselves.

Auto-response#

The email someone gets when their email becomes a ticket, like "We have received your request and created Ticket #1042". Each department has its own. Pick one from Department when there's more than one.

• The switch turns it on or off for that department. Off by default.
• The editor holds the wording. Type {{ or select Insert variable to add a value that's filled in per ticket, like the ticket's number, the requester's first name or your account's name. See Variables. The requester reads it, so staff-only variables aren't offered. Wording saved with the first placeholders ({{District_Name}}, {{Ticket_ID}} and so on) keeps working.
• Preview shows the email with a sample ticket. Preview with… fills it in for a real ticket you enter.
• Use the default wording puts back schoolOS's standard message. If you save the default wording, you get any future improvements to it.

Select Save auto-response.

It's for email only. When AI answers the ticket, its answer goes instead, so the requester gets one email, not two. Either one has a View your request button that opens the request without a password (secure tracking links). Turn it on so people know their email arrived and have a ticket number to quote. Leave it off if your team replies quickly anyway.

Task templates#

A task template is a list of tasks that go onto a ticket together, like everything IT does for a new hire: create the account, set up the laptop, hand over the badge. Select New template, or Edit on one in the list.

• Name and Kind (Onboarding, Offboarding or Custom). Kind only groups them.
• On (when editing). Off keeps the template but stops it being applied.
• Tasks. Each has a name and optional details. Both can use variables, filled in from the ticket when the template is applied: Set up {{requester.first_name}}'s laptop at {{requester.location}}. Type {{ or select Insert variable, and Preview with… fills them in for a ticket you enter. Due sets the due date in days after the template is applied. Must be done before the ticket closes keeps the ticket open until the task is done. Use the arrows to reorder tasks.

Select Save template. A task that was given an owner role or a department when it was made keeps them.

For example, a district's HR ticket for a new teacher gets the "New staff member" template: "Create {{requester.first_name}}'s account" due the same day, and "Deliver a laptop to {{location.name}}" due in three days, both before the ticket can close.

Remove personal information#

Off by default. When on, schoolOS removes the kinds of information you tick from ticket text, replies and the emails they came from, once they're older than the days you choose. They read as <redacted> from then on. It runs every night.

• What to remove. Social Security numbers, Credit card numbers, Passwords and Student names. All four are ticked to start. At least one has to stay ticked. Passwords means ones someone typed out, like "password: Summer24!". Student names come from your roster.
• Remove after. 7, 14, 30, 60, 90, 180 or 365 days from when it was written. 30 by default.

Turning it on asks you to confirm first.

Turn it on if your district's policy limits how long you keep this kind of information. A shorter window protects more; a longer one leaves agents more history to work from.

Match Remove after to how long tickets really stay useful. With a reopen window of 5 days, 30 days keeps names readable while a ticket might still come back, and removes them well before the next school year. Untick Student names if agents look back at old tickets to find which student had a device, like a Chromebook 1:1 program checking a repeat breaker's history; the other three are rarely needed after a ticket closes.

Support email#

Forward your support mailbox to the address shown here, and every email becomes a ticket. A reply that keeps the ticket number in its subject, like [#123], is added to that ticket instead.

An email sent to more than one district's address opens a ticket in each district, and each sees only its own. The same email arriving twice, like a copy your mailbox forwards again, still makes just one ticket.

An email up to 18 MB comes in whole, attachments included. A larger one still becomes a ticket or reply, from its sender and subject (and its text, when it comes before the attachments), with a note that its attachments were too large to bring in; ask the sender to send them smaller or as a link.

Quoted history is removed from an email, so a ticket or reply shows only what the sender wrote. A forwarded email is the exception: when someone forwards one message to the support address (its subject starts with Fwd: or FW:), the whole forwarded message becomes the ticket's description, formatting included. Who the ticket is for is under Forwarded email.

• Forwarding address. Your account's address. Copy copies it. Change edits the part before the @: lowercase letters, numbers and hyphens, up to 40 characters. If you change it, update the forwarding rule in your mailbox too.
• Department addresses. When you have more than one department, each gets its own address, and mail sent there opens the ticket in that department. Change edits it; Reset to… goes back to the department's URL slug. The default department's address is the forwarding address.
• Catch-all. When your workspace has its own address, this makes any address at your email domain (like helpdesk@…) create tickets, not only the forwarding address. Turn it on if people already email several addresses, like help@, tech@ and support@ from years of different flyers. Leave it off to keep stray mail out: with it on, a typo like helpdsk@ becomes a ticket too.
• Last email received, and Recent messages with how each was handled: New ticket, Reply, Ignored or Rejected, with a link to the ticket.
• Set up forwarding. Step-by-step instructions for Google Workspace (Admin console, One Gmail mailbox or Google Group) and Microsoft 365, with your real addresses filled in.

Replies from schoolOS come from your outbound email sender. The forwarding address only receives.

A team can also have its own email address.

If your workspace uses its own domain rather than a schoolOS one, that domain has to deliver mail to schoolOS first. Contact schoolOS support to set that up.