Approvals
Have a request approved before the team works it. Approval steps in a checklist say who approves, any one or all, and when a step applies; a Request topic applies them to every new ticket.
Some requests need a yes before anyone works them: a second device, a software license, admin access to an app. In schoolOS an approval is a step in a checklist template. Build the checklist once, with its approvals and the work that follows, and add it to a task or ticket (From a template), or have a Request topic apply it to every new ticket.
A request moves one stage at a time: Sent, then each approval, then the team. While any approval is open the ticket waits in Awaiting approval with its SLA clock paused. Once the approvals are done it goes back to Open and is routed as usual. A denial stops it and tells the requester why.
Build an approval#
Open Helpdesk › Tasks and select Templates. Pick a checklist, or select New template › Checklist, then Add an approval. Each approval step has:
- A name. Say who approves, in the requester's words: "Principal", "Director of Technology". The requester sees it.
- Who approves, and who that is. See Who approves.
- How many, when it can match several people. See Any one or all of them.
- If nobody matches. See If nobody matches.
- Due. Days after the checklist is added, or before or after its key date. See Due dates and key dates.
- Only when. See Only when.
Drag a step by its handle to reorder it (or focus the handle and use the arrow keys). One step at a time opens each step when the ones before it are done or skipped; turn it off and every step opens at once. Select Save, or press ⌘S (Ctrl+S).
Preview for a person shows who each step would go to for someone real, before anyone asks: pick a requester and each step reads, for example, "Principal → Priya Patel". A step that depends on the ticket itself (its device type, a field, its priority) reads "depends on the request".
Who approves#
| Choose | Who gets it | | --- | --- | | A specific person | The person you pick. | | A team | The team's members. With Any one, one step on the team that any member decides; with All of them, a step for each member. | | A role at the requester's school | Everyone holding that role at the requester's schools: their home location and any other locations they work at. A requester with no school uses the ticket's location. This is how a principal approves requests from their own school: make a Principal role and give it to each principal at their school. | | A role across the account | Everyone holding that role, anywhere. |
The requester never approves their own request through a team or a role. Approvers can be anyone active in your account; department membership doesn't limit who approves.
Any one or all of them#
When a step matches several people, each of them gets their own approval, in the same stage:
- Any one. The first approval settles the stage. The others' steps show Skipped ("Priya Patel already approved"), and their email links stop working.
- All of them. Each must approve before the next stage opens.
A denial from anyone stops the request either way.
If nobody matches#
Nobody holds the role at that school, the team is empty, or the person has left. The step goes to the person you pick here; without one, to the task's assignee; without one, it waits unassigned and says "assign an approver". At most 25 people get one step.
Only when#
A step can apply only sometimes. Every condition must hold, or the step is Skipped and the next one opens. They're checked once, when the checklist is applied, so the preview is exactly what happens.
- The requester already has a device (or doesn't): of the ticket's device type, of any type, or of a type you pick. Counts devices assigned to them now that aren't retired.
- A ticket field equals a value. Fields are matched by the field, not its name, so renaming it doesn't break the condition.
- A ticket number is at least or less than an amount: a number field on the ticket (a cost, a quantity) against a threshold you type. "Amount is at least 1,000" adds the director's approval to requisitions of $1,000 and up; "is less than" keeps a step for the small ones. A value typed with a currency sign or commas still reads as its number. A ticket with no value in the field, or no number in it, skips the step.
- The priority is one or more priorities.
A standard step can have conditions too, for work that only some requests need.
Reporting on approvals#
Every decision is a task, so Insights counts them. The Approvals section of the Tickets tab starts with Approvals by Request Type: approved against denied for each topic, so requisitions and transfer requests each show their own numbers. Drill into a bar to see the tickets. Approved vs Denied by Month, Approval Rate, Awaiting Approval and Decisions by Approver sit beside it, and the report builder has the fields behind them:
- On Tickets: Approval Outcome (Approved, Denied, Waiting, Not needed, or No approval) with Approved Requests, Denied Requests, Awaiting Approval and Approval Rate. A ticket counts once, whatever its checklist's steps: one denial makes it Denied, one open step keeps it Waiting, and it's Approved once an approver said yes and nothing is left open. Filter by Topic and any ticket field, so "requisitions under $1,000, approved vs denied" is a filter on the field and a bar per outcome.
- On Tasks: Kind (Approval step or Task), Decision (Approved, Denied, Waiting, Skipped), Decided By, Request Outcome on the checklist's own task, and the linked ticket's Ticket Topic and Ticket Topic Category, with Approvals Approved, Approvals Denied, Approvals Waiting, Requests, Requests Approved, Requests Denied and Approval Rate. Date the report by Decided date to count decisions when they were made.
Ask Otto the same question in words: "How many requisitions were denied last month?"
When a request is denied#
Deny needs a reason. Then:
- Every step still open or waiting is Skipped, saying which approval stopped it, and the checklist's task is Denied.
- The requester gets an email with the approver's name and reason.
- When denied on the checklist decides the ticket: Close the ticket (the default), or Keep the ticket open so the team can follow up.
While a ticket waits#
While any approval on a ticket's checklist is open or waiting its turn, the ticket is in Awaiting approval, a status meaning of its own (Statuses). Its SLA clock is paused, the way Pending pauses it, and it isn't routed to a team yet. When the last approval is decided it returns to Open, the clock picks up where it stopped, and routing runs as usual. The rest of the checklist (the fulfillment steps) carries on.
Only a ticket that is New or Open starts waiting: a ticket someone parked or solved stays where they put it.
Every status catalog gets an Awaiting approval status when approvals are turned on. Rename it or change its color in Statuses; keep its meaning.
On a Request topic#
A topic's page has Add these to new tickets: every new ticket with the topic gets those templates, from every channel (the form, email, schoolAgent, the public helpdesk, a kiosk, bulk entry). A checklist there with approvals makes the ticket wait for them. Subtopics without their own list take their parent's. Imported ticket history never gets them. (Until your account's database is updated for it, a Request topic has a single Checklist there instead.) Nobody adds it by hand, so there's no preview: steps get the checklist's own settings, steps for the ticket's assignee or team are filled in once the ticket is routed, and a checklist with a key date counts from the day the ticket is created. See Topics.
What an approver sees#
A new approval shows in the bell, at the top of My tasks as Your approvals (where Approve and Decline on the row decide it after one confirmation, with a note for the requester, and a reason when declining), and in the approver's email. On the ticket list, a ticket waiting on your approval shows Awaiting your approval and, in the list's default order, comes first under Waiting on your approval, and on the ticket the Tasks icon in the rail shows an amber badge. Approve or deny from either place on the ticket: the Waiting on you card pinned at the bottom of the conversation, just above the reply box, or the step under its checklist in the Tasks panel. Both have Approve and Deny while it's waiting on you (Approvals on a ticket). Every request and decision is in the ticket's conversation, in order with the messages, as a record: "Approval requested from Grace Miller (Principal) and Rich Watson (IT director)" never changes after it's written, and each entry names its task (TSK-0082), which opens it.
The approval opens with everything needed to decide: who asked and from which school, what they asked for in their words, the devices assigned to them now, and where the request stands. Then:
- Approve, with an optional note. The requester reads it in the email that says it was approved.
- Deny, with the reason the requester will read.
- Ask a question. Sends the requester a message on the ticket (they get it by email), and you follow the ticket to hear the answer. Their reply shows in the approval.
- Out? Hand to someone else. Pick someone in your account (not the requester). They decide instead of you and get it by email; your links stop working.
Only the approver decides: the person it's assigned to, or a member of its team. No role overrides that; an admin who should decide assigns it to themselves first, which leaves a record.
Approve from email#
The approver's email has Approve and Deny buttons. Each opens a page, in your account's logo and colors like the email, that shows the request and asks you to confirm; nothing is decided until you do, so a mail scanner that follows links can't approve anything. Approve offers an optional note; Deny asks for your reason. The requester reads either one. The links work once, only for you, for 3 days; after that, open the approval in schoolOS.
Reminders#
Reminders on a checklist with approvals: Don't remind, or remind approvers after 1, 2, 3, 5 or 10 business days (Monday to Friday) without a decision. Each reminder is a fresh email with new links, at most three times.
What the requester sees#
On the ticket in the helpdesk, the requester's conversation shows Approval requested and each decision as they happen, with no buttons. In schoolAgent › My tickets, a ticket with approvals shows where it stands: Sent, each approval, then the team, in plain words: "Priya Patel (Principal) is reviewing this. You'll get an email when it's decided; nothing to do for now." They get an email when it's approved (and with the team, with any note an approver left) or not approved (with the reason).
Which should I choose?#
| You want | Do this | | --- | --- | | The requester's principal to approve, whoever that is | A role at the requester's school with a Principal role; If nobody matches: your director. | | Anyone on the budget office to sign off | A team, Any one. | | Every member of a committee to agree | A team, All of them. | | A second look only when it's a second device | Add the step with Only when: the requester already has a device of the ticket's device type. | | The request closed when it's denied | Leave When denied on Close the ticket. | | The team to talk to the requester after a denial | When denied: Keep the ticket open. |
Was this article helpful?
Related articles
- TasksWork that isn't a ticket, or that a ticket needs done. See tasks as a table, a board or a calendar, add one-time, recurring or approval tasks, start them from templates, and work a task in its own view.
- Ticket topicsThe 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.
- Ticket statusesRename, recolor, reorder and add the statuses tickets move through. Each status has a meaning (New, Open, Pending, Solved or Closed) that decides SLA clocks, reopening and reports.
- SLA targets and business hoursSet a department's default first-response and resolution targets per priority, count only business hours, warn and escalate before a target is missed, and check that SLA clocks are running. Topics can set their own.
- My ticketsFollow the requests you've made for help, read the support team's replies and answer them, close a ticket once it's fixed, and ask for help with a new ticket. Covers both My tickets in schoolAgent and the My requests page.
- TicketsThe helpdesk inbox. Pick a view, search and filter tickets, choose columns, change status, priority and assignee right in the list, close, archive or restore many at once, export to CSV, and log a new ticket.
- How tickets are routedWhat happens between a ticket arriving and a person working it. The order of the steps (channel, rules, AI triage, topic route, location's team, default team, team method), which step wins, and how to see why a ticket went where it did.
Updated October 7, 2026
