Automate work with workflows

A workflow is a rule: when something happens to a record, only if it matches your filters, then do the steps you choose. Use it for the busywork, like telling a team about every new urgent ticket or tagging tickets from one school.

Find it at Admin › Account › Workflows.

If you manage more than one account, choose Account on the Workflows list before opening New workflow or editing a rule. The builder uses that account's records and fields and returns to the same account after saving. A builder link without an account asks you to choose one on the Workflows list.

Who can use workflows#

Every account has workflows. Two things have to be true:

• Your plan has something to automate. Tickets and tasks need schoolHelpdesk. Assets and parts need schoolAssets. You only see the record types your account has.
• Your role has Manage workflows. Set it in Admin › People › Roles.

If your plan has nothing to automate, the page says Workflows aren't enabled for this account. Talk to your schoolOS contact.

The list#

Each workflow shows as one row, in the order they run (see Run order):

• Order: where it runs among its department's workflows. Drag a row by its handle to move it.
• Department: the department it's for, or Every department. Shown when your account has more than one department.
• Name, with Built-in on the workflows schoolOS gives every account (see Built-in workflows), Off when it's turned off, a problem badge when something in the rule is broken (see Problems with a workflow), and its description.
• When: a badge for its record type and trigger, like Ticket · event, Asset · scheduled or Ticket · on a schedule, and when it runs.
• Steps: how many filters and actions it has.
• On: a switch that turns the workflow on or off right away. Off means it stays saved but never runs.

Search by name or description, and filter by Record, Trigger or Status. Select a row to open the builder. Its … menu has:

• Edit opens the builder.
• Move up and Move down change the order on a phone, where there's no drag handle.
• Run history shows what happened each time it ran. See Run history.
• Duplicate makes a copy named "(copy)" and opens it. The copy is always off, so the same rule never runs twice by accident. Change what differs, then turn it on.
• Delete removes the workflow and all its run history, after you confirm with Delete workflow. Built-in workflows can't be deleted; turn them off instead.

Built-in workflows#

schoolOS sends some notices on its own. They're listed as workflows, marked Built-in, so you can see exactly what they do, change them, or turn them off:

| Workflow | When | What it does | | --- | --- | --- | | Email the requester when a ticket is opened | A ticket is created, unless it came in by email or from a repair kiosk | Emails the requester that you have their request, with a link to follow it. Tickets that come in by email get the department's auto-response instead, and kiosk drop-offs their receipt. Someone who submits tickets for many devices at once for themselves isn't emailed for each; a ticket you open for yourself one at a time still is. | | Tell the assignee when a ticket is assigned | A ticket is assigned: created with an assignee, or handed to someone, by a person or by routing | Notifies the person it's assigned to in the bell ("Pat assigned you #123 …") and by email. A ticket given to a team with nobody picked yet waits until someone is. | | Tell the assignee when a task is assigned | A task is assigned | The same, for tasks. | | Set the status to Assigned when a device is checked out | A device is checked out on Assets › Check-in/out | Moves it to your status that means Assigned. | | Set the status to Available when a device is checked in | A device is checked in, with Set status to In Storage off | Moves it to your status that means Available. | | Set the status to In storage when a device is checked in to storage | A device is checked in with Storage tracking and Set status to In Storage on | Moves it to your status that means In storage. | | Tell the requester when their ticket is solved | A ticket moves to a status that means Solved, unless it was merged into another | Emails the requester that it's solved, with a link to reply or reopen it. | | Tell the team when a ticket comes in unassigned | A new or open ticket still has nobody on it 10 minutes after it came in | Tells its team in the bell, or its department's staff when it has no team. Routing assigns most tickets within seconds, so this is only the ones it couldn't. Once per ticket. | | Clear the assignee when a device is set to Retired or Disposed | A device moves to a status that means Retired or disposed, and it's assigned to someone | Clears Assigned to, so a retired device isn't still on someone's list. |

They start on, run first, and belong to every department. Edit them like any workflow: change the wording, add a filter so they only run for some tickets, add a step. Turn one off to stop it: with Tell the assignee off, nobody is notified when a ticket is assigned to them. Nobody is ever notified about assigning something to themselves. With a check-in/out workflow off, a scan still records who has the device and where it is, and leaves its status alone: the page sets no status of its own.

The requester's confirmation email is written in the rich text editor, so you can see the whole message, change its wording and add your own lines, with variables for the ticket's number, subject and tracking link. Every email a workflow sends The Requester about a ticket arrives in your district's branded email with a View your request button and "Or just reply to this email." under it: the button opens that one request without a password, while it's open and for 7 days after it's solved or closed (secure tracking links). In those emails the ticket's tracking link variable is the same link. Replies go to the ticket's support address and are added to the ticket, which notes each email on its timeline.

Built-in workflows can't be deleted. Your account only gets the ones for products it has. A built-in workflow added later reaches accounts that already have the others the next time it's needed, on, the same way.

Run order#

When something happens to a record, its workflows run one after another, top to bottom: the Every department workflows first, then the workflows for the record's department, each in the order you set. A workflow sees what the ones above it changed, so order matters: put "set the topic" above "notify the topic's team".

To change the order, drag a workflow by its handle in the list. A workflow moves only within its department; to move it to another department, change its department scope. New workflows go to the bottom of their department. Clear the search and filters first: the handles turn off while the list is filtered.

Then stop#

Turn on Then stop in a workflow's General step to make it the last word: when it matches a change, the workflows below it don't run for that change. If its filters don't match, the ones below run as usual.

• Building leads first: in the IT department, put "Lincoln Elementary tickets go to Pat" above "Every new ticket goes to the Help Desk team", and turn on Then stop in the first. Lincoln's tickets go to Pat and only Pat; everyone else's go to the Help Desk.

A stop in an Every department workflow stops the department's workflows too. Then stop needs database migration 330; until it runs, the builder says so when you save.

Test workflows#

Test workflows on the list, or Test in the builder, runs your rules against a real record without changing anything or notifying anyone. Pick the record type, what happens to it (like Ticket is assigned), and the record: a ticket number, a task number like TSK-0042, an asset tag or serial number, or a part number.

You see every workflow in order:

• Would run, or why not: it runs on something else, its filters don't match (each filter shows whether it passed), or a workflow above it stopped the rest.
• For each one that would run, its steps in plain words, with every placeholder filled in from that record. A placeholder that would come out blank is pointed out.

From the list it tests the workflows that are on. From the builder it tests the rule you're editing, before you save it.

The record is taken as it is now, and the change you pick is assumed to have just happened. So filters that look for a change (changed, changed to, changed from) don't match in a test; they do when the change really happens.

Create a workflow#

Start from a template#

From a template beside New workflow offers ready-made workflows. A template opens in the editor unsaved and turned off, like a draft: check its filters, who it notifies and its timing, then save, and turn it on when you're ready. You only see the ones your account can use: it has the products they're about, and a device template's provider is connected with write access.

| Template | Needs | What it does | | --- | --- | --- | | Damaged device → repair ticket | schoolAssets and schoolHelpdesk | When a device is set to Damaged: Open a ticket about this device, adding it to its open ticket, and assigning a new one by the device's location. | | Device health failed → ticket | schoolAssets and schoolHelpdesk | When a device fails a health check: the device added to its open ticket, or a new one. | | Repair ticket solved → device back to Available | schoolAssets and schoolHelpdesk | When a ticket is solved, its devices that are Damaged, In repair or Out for repair move to your Available status. | | Lost or stolen → ticket for follow-up | schoolAssets and schoolHelpdesk | When a device is set to Lost or Stolen: a follow-up ticket, and the techs at its school told. | | Lost device: Lost Mode, then erase | schoolAssets, Jamf Pro two-way | When a Mac or iPad is set to Lost: Lost Mode on, then, 14 days later and still lost, erase. Asks first. | | Found device: Lost Mode off | schoolAssets, Jamf Pro two-way | When it goes from Lost to Available: Lost Mode off. | | Retired device: erase it | schoolAssets, Jamf Pro two-way | When it's set to a status that means Retired or disposed: erase. Asks first. | | Lost Chromebook: disable it | schoolAssets, Google Devices with device management | When a Chromebook is set to Lost: disable it. | | Found Chromebook: re-enable it | schoolAssets, Google Devices with device management | When it goes from Lost to Available: re-enable it. | | Retired Chromebook: deprovision it | schoolAssets, Google Devices with device management | When it's set to a status that means Retired or disposed: deprovision it. Asks first. | | Lost iPad (Intune): Lost Mode on | schoolAssets, Microsoft Intune with device management | When an iPad or iPhone is set to Lost: Lost Mode on, with your return message. Supervised devices only. | | Found iPad (Intune): Lost Mode off | schoolAssets, Microsoft Intune with device management | When it goes from Lost to Available: Lost Mode off. | | Retired device (Intune): retire it | schoolAssets, Microsoft Intune with device management | When it's set to a status that means Retired or disposed: retire it in Intune, removing the school's apps and data. Asks first. | | Checked out past due → remind | schoolAssets | A spare checked out for 14 days with no change: the person who has it is emailed, and their school's techs told. Once per checkout. | | Warranty ending soon → tell asset admins | schoolAssets | Every morning, devices whose warranty ends 30 days from that day: your asset admins are told. | | Unassigned for 24 hours → tell the department leads | schoolHelpdesk | A ticket nobody has picked up in a day. Once per ticket. | | Not worked for 30 days → alert the assignee and department leads | schoolHelpdesk | Nobody on staff has changed its status, added a note or replied in 30 days. Once each time it goes quiet. | | Pending with no reply in 48 hours → nudge the requester | schoolHelpdesk | A Pending ticket whose requester hasn't answered 48 hours after our last reply: a reminder email. Once per reply of ours. | | Open or on hold for 72 hours → nudge the assignee | schoolHelpdesk | A ticket still open or on hold 72 hours after it came in: its assignee is reminded. Once per ticket. |

With PDQ Connect connected you also get PDQ's templates. The durations are a starting point: change them before you save.

Draft one with Otto#

Type /workflow in Otto, then what it should do in your own words: "/workflow when a ticket has waited two days without an update, notify its assignee". Otto answers with the rule in plain English and Open in the workflow editor. The link opens the builder with that rule filled in, turned off and unsaved; review each step, change what you like, then Save. Nothing runs until you do. "Draft a workflow that…" works too. If the request isn't something a workflow can do here (a report, a one-time change), Otto says why. Only people who can manage workflows get a draft.

Select New workflow to start from scratch. The builder shows the rule as numbered steps. Select a step to open it. Selecting another folds the first, so the step you're working on is the one on screen.

General#

• Name. Required. Say what it does: "Notify the team on new urgent tickets."
• Description. Optional. What it automates, for the next person.
• Enabled. On by default. Turn it off to save a rule you're not ready to run.
• Then stop. For rules that run on a change. When this one matches, the workflows after it don't run for that change. See Run order.
• Ask before running. For rules that run on a change. See below.

Ask before running#

Turn on Ask before running and a person's change that would start the workflow doesn't run it on its own: they're asked first. A workflow with an action that can't be undone (Erase the device, Wipe users, Powerwash, Deprovision) always asks, and the toggle says so. Those actions also only work in workflows that start on a change, never on a schedule, because a person has to confirm them.

The change itself is always saved. Only the workflow waits for the answer. Changes no person makes (an import, a sync) can't be asked about, so a workflow that asks first doesn't run for them, and the record's timeline says so. Ask before running needs database migration 423; until it runs the toggle is off, and the actions that can't be undone aren't offered.

The "Run the workflow?" prompt#

Right after the save, the person who made it sees Run the workflow "Lost device"?: "Setting LIN-0042 to Lost starts this workflow. It will:" and the workflow's steps, numbered, in plain words, with Open the workflow to read it first. Then Don't run it or Run the workflow. For an action that can't be undone, Run the workflow stays off until they type ERASE and the asset tag; for a change to several devices at once, the number of devices.

• A change to many devices (a bulk edit, status, pool, assignment, undo or delete) is one prompt per workflow for the whole batch: "Setting the status to Lost on 12 devices starts this workflow, once for each."
• Where it asks: a device's page and its quick status change, the device edit page, inline and bulk edits on the asset list, Assets › Check-in/out, and a ticket's page for ticket workflows with Ask before running on.
• Running it checks again. The person has to still be able to change every record, the workflow has to be unchanged and on, and the prompt can't have expired. If any of that isn't true, it doesn't run and says why.
• Unanswered prompts expire after 15 minutes, and the workflow doesn't run.

Every answer goes on each record's timeline, with a link to the workflow: "Pat Lee ran the workflow Lost device" (Approved), "Pat Lee didn't run the workflow Lost device" (Not run), or "No one ran the workflow Lost device; it expired".

Choose a trigger#

Step 1, When:

• Record. Ticket, Task, Asset or Part, as your plan allows. Changing it clears your filters and actions, because each record type has its own fields.
• Department. Shown when the record type has departments. Pick one department, and the rule runs only on that department's records: the safer choice, since an IT rule never touches Facilities work. All departments runs it on every record, including departments you add later; choose it only when the same rule is right for all of them. A new workflow starts on All departments. A rule built with a more complex department filter shows Custom department filter.
• Trigger. How the rule starts:
  • On a change. Runs the moment a record changes. Then pick the Event: created, updated or deleted, or one of the moments below. Tickets have no "deleted", because tickets can't be deleted. A change made to many records at once runs it for each record, as if they'd been changed one at a time: Submit ticket... on 500 devices runs your "created" rules for each of the 500 tickets. The one exception is the built-in "Email the requester" workflow, below. Large batches can take a few minutes to finish.
  • After time elapses. Runs when a record has existed for, or has been untouched for, an Amount of minutes, hours or days. Tickets can also count from the last reply: has had no reply from us for, or has had no reply from the requester for, and from the last time your team worked it: hasn't been worked by us for.
  • On a schedule. Runs at set times, for every record that matches your filters. Pick how it Repeats (Every day, Every weekday, Every week on the days you choose, or Every month on a day, where Last day is each month's last), and the time At, in your account's time zone. "Every Monday at 7:00 AM, for each open ticket untouched for a week, remind the assignee." A scheduled rule needs at least one filter, so it can't run for every record you've ever had.

schoolOS checks scheduled workflows every few minutes, so one runs shortly after its time is up, not to the second. Each record gets it once:

• Has existed for runs once per record, ever.
• Has been untouched for runs once, then again only after the record changes and goes quiet for the full time again. Changes by people and by other workflows restart the clock. Changes this workflow makes itself don't, so a rule that updates the record it runs on doesn't repeat.
• Has had no reply from us for counts from the last public reply by a person on your team, by email or on the ticket. Internal notes don't count, and neither do replies from a workflow or the AI assistant, so a rule that sends a reminder reply doesn't reset its own clock. A ticket nobody has answered yet counts from when it came in. It runs once, then again only after someone replies and the ticket goes quiet for the full time again. Editing the ticket (a tag, the priority) doesn't restart it.
• Has had no reply from the requester for works the same way, counting from the requester's last reply on the ticket, by email or from their tracking link.
• Hasn't been worked by us for counts from the last status change, internal note or public reply by anyone but the requester (not the AI assistant). A ticket nobody has worked yet counts from when it came in. It runs once, then again after someone works it and it goes quiet for the full time again. It needs database migration 423.
• On a schedule runs once per record each time it comes round. It starts from its next time after you save it or turn it on. If schoolOS can't run it within 12 hours of its time (an outage, say), that time is skipped rather than sent late.

Moments

A moment runs once, when it happens, so "Ticket is assigned" runs on the save that assigns it, not on every later save. Each record type has its own:

| Record | Moments | | --- | --- | | Ticket | is assigned (to a person or a team), changes status, is solved, is closed, is reopened (from Solved or Closed back to open), comes in by email, gets a reply from the requester (by email, on the ticket, or from their tracking link), is sent for approval, is approved, is denied, has an SLA at risk, breaches an SLA, gets a device linked, gets a device unlinked | | Task | is assigned, is completed, is approved, is denied (approval steps) | | Asset | is assigned, changes status, fails a health check, passes a health check again, is checked out, is checked in (on Assets › Check-in/out), gets a part linked, gets a part unlinked, is linked to a device, is unlinked from a device (a cart's or kit's member, or the cart or kit itself), is linked to a ticket, is unlinked from a ticket; with PDQ Connect: shows up in PDQ, goes missing from PDQ, hasn't been seen by PDQ for a while, has needed a restart for a while, is low on disk space, has a new critical or exploited vulnerability, has an app that's behind, finishes a PDQ deployment, fails a PDQ deployment (PDQ workflows) | | Part | falls below its minimum (quantity in stock drops below the minimum quantity) |

A moment is also an update, so a rule on updated runs too, except the link moments: linking a part, a device or a ticket changes nothing on the record itself, so only rules on that moment run. "Stale" is After time elapses, has been untouched for.

Some fields are only there on the write that carries them, for filtering these moments: Checked in to storage (Yes or No, on every check-in), Linked part and Linked part: category, Linked device: asset tag and Linked device: type, and Linked ticket: number and Linked ticket: topic. On any other event they're empty. "Asset is checked in, only if Checked in to storage is Yes" is how the built-in In storage workflow works; "Asset gets a part linked, only if Linked part: category is Battery" tells the team about a battery swap.

Which should I choose?

| Option | Runs | Choose it when | | --- | --- | --- | | On a change | The moment someone creates, updates or deletes a record. | Something should happen right away: tell the team about an urgent ticket, tag a ticket from one school. | | After time elapses, has existed for | Once per record, when it reaches an age. | A deadline from when the record was made: a ticket still open 3 days after it came in. | | After time elapses, has been untouched for | When nobody has touched the record for a while, and again after each new quiet spell. | Something has stalled: a work order nobody has updated in 5 days. | | After time elapses, has had no reply from us for | When nobody on your team has replied to the requester for a while. Edits don't count, only replies. | A request waiting on you: a ticket with no reply from us in 60 days. | | After time elapses, has had no reply from the requester for | When the requester hasn't answered for a while. | Waiting on them: close a ticket after 14 days with no reply from the requester. | | On a schedule | At the times you set, for every record that matches. | A routine: every Monday morning, nudge the assignees of tickets still waiting on parts. |

• A Facilities team handling HVAC work orders: Ticket, After time elapses, has been untouched for 2 days, department Facilities, filter "Status is not Closed". Action: Notify a person or team, Email, to the Facilities supervisor. A ticket about a broken boiler that sits for two days without an update emails the supervisor once; if a tech updates it and it stalls again, it emails again two days later.
• A district that wants urgent tickets seen fast: Ticket, On a change, created, filter "Priority is Urgent". Action: Notify in app, to the IT team. The notification arrives as the ticket is submitted, not minutes later.

When a rule first turns on, it can catch many records at once. schoolOS works through them a batch at a time, oldest first, over the next few checks. Filters under Match ALL of these on fields like status, priority, type, location, team or assignee narrow the search itself, so records that don't match them never hold up the ones that do.

A change made to many assets at once (a bulk edit, status, pool, location, assignee, link or delete, or an Undo of one) runs your asset workflows on each asset it changes, just as if each had been changed on its own. Assets the change leaves as they were don't run them.

Only changes people make start an On a change workflow. Changes from imports, from MDM syncs and from other workflows don't, so one rule can't set off another in a loop. There are three exceptions, and only rules on that moment run: is assigned, when routing assigns a ticket; approvals and SLAs: is sent for approval, is approved, is denied, has an SLA at risk and breaches an SLA, which schoolOS makes happen; Device Health's fails a health check and passes a health check again; and PDQ Connect's moments, which its syncs and deployments make happen.

Filter which records it runs on#

Without filters, the rule runs on every record that triggers it. To narrow it, select the + between steps and choose Filter. This adds the Only if step with two groups:

• Match ALL of these. Every filter here has to match.
• And match ANY of these (optional). If you add any, at least one has to match too.

Put a filter under ALL when every record must meet it, and use ANY for a list of alternatives. For example, to act on urgent tickets from either of two high schools: "Priority is Urgent" under ALL, and "Location is Central High" and "Location is North High" under ANY. For one field, "Location is any of Central High, North High" under ALL does the same in one filter.

A status can be filtered two ways. Status is one of your statuses. Status meaning (tickets and assets) and Status kind (assets: Lost, Damaged, Retired and the other built-in kinds) match any of your statuses with that meaning, even ones you rename or add later: "Status kind changed to Lost" works whatever your lost status is called. Templates and built-in workflows use them for that reason.

A date filter from a template can count from the day the rule runs: today, today+30 or today-7, shown as text you can change. "Warranty expiration is on today+30" is a device whose warranty ends 30 days from the day the rule runs.

Each filter is a field, a comparison and a value. Fields are the record's own, plus your account's custom fields for tickets and assets. Fields that hold a status, a person, a location or another list give you a picker of your real values, never a text box. If your account has no values for one yet, the box says No options configured for this account.

Ticket Status and Priority show the values effective in the workflow's department. For All departments, values with the same name in different departments include their department names so you can choose the right one. A shared value appears once when several departments use the same ID.

The comparisons depend on the field: is, is not, is any of, is none of, contains, is greater than, is empty and so on. Dates read is before, is after and is on, and compare whole days.

Three comparisons look at the change itself: changed, changed to and changed from. Use them on an updated trigger when you mean "the moment it happens".

Change comparisons aren't offered for scheduled triggers or for custom fields.

To remove the whole step, select its trash icon. The rule then runs on every record again.

Actions#

Select the + and choose Action. A rule needs at least one. Actions run in order, top to bottom. To put a new one above an existing one, use the + above it.

Each step's action is picked from the Add an action menu, grouped in this order: Record (fields, status, tags, notes), Notify or reply, Tasks and approvals, Wait, then Devices, with a group for each device service you've connected (Jamf Pro actions, Google Devices actions, Intune actions, PDQ Connect actions; select a group's name to fold it), then Other. Search actions finds one in any group. A service connected read only shows its group grayed out with one line on why and a link to its integration page, where you turn on write access. Actions that can't be undone say Asks first.

The actions you can pick depend on the record type:

| Action | Records | What it does | | --- | --- | --- | | Update a field | All | Sets a field on the record. Pick the field, then a value, from the same pickers as filters. On tickets this includes Topic. | | Set the status | Assets | Moves the device to one of your statuses, or to Your Assigned status, Your Available status, Your In storage status and so on: whichever status your account marks with that meaning, even if it's renamed later. | | Reply to the requester | Tickets | Posts a public reply on the ticket and emails it to the requester. Counts as the ticket's first response. | | Add an internal note | Tickets, tasks | Adds a note only staff see. | | Add a tag | Tickets | Adds a tag by name. Creates the tag if it doesn't exist. | | Remove a tag | Tickets | Removes a tag you pick. | | Notify in app | Tickets, tasks | Sends a message to the bell of people, teams, the assignee or the requester, signed with the workflow's name. | | Notify a person or team | All | Sends an email. On assets and parts, it can also send an in-app notification. | | Create a task | Tickets, assets | Creates a task with a name, and optionally who it's for and a due date in days. | | Reply to the requester | Tickets | Adds a public reply and emails it to the requester, signed as your schoolAgent. | | Set location to the requester's | Tickets | Sets the ticket's location to the requester's school or building. | | Assign by location | Tickets | Gives the ticket to the team that covers its location, and optionally to one of its people. | | Add a task or checklist from a template | Tickets | Adds one of your task or checklist templates to the ticket. | | Send for approval | Tickets | Adds a checklist with approval steps; the ticket waits in Awaiting approval. | | Add followers | Tickets | Adds people as followers, so they get its public replies by email. | | Set its devices' status | Tickets | Moves the ticket's linked devices to one of your statuses, or to Your Available status and so on. With Only devices in repair on (the default), a device that isn't Damaged, In repair or Out for repair is left alone. | | Open a ticket about this device | Assets | Adds the device to the open ticket it belongs on, or opens one. See below. | | Wait | All | Waits minutes, hours or days before the steps after it. See Wait. | | Jamf Pro actions | Assets | Turn on Lost Mode, Turn off Lost Mode, Play the Lost Mode sound, Request its location, Lock the device, Restart, Shut down, Update inventory, Clear the passcode, Set Recovery Lock, Set a Jamf field, Erase the device (asks first). See Device actions. | | Google Devices actions | Assets | Disable the device, Re-enable the device, Reboot, Update an annotated field, and, asking first, Wipe users, Powerwash and Deprovision. See Device actions. | | Intune actions | Assets | Turn on Lost Mode, Turn off Lost Mode, Play the Lost Mode sound, Request its location, Lock the device, Restart, Sync with Intune, Rename the device, and, asking first, Retire and Wipe the device. See Device actions. | | Deploy a PDQ package, Restart with PDQ, Set a PDQ custom field, Wait for the deployment result, Open a ticket per vulnerability, Open a ticket about the device | Assets (and tickets, for the first four) | With PDQ Connect connected: see PDQ workflows. |

Some details worth knowing:

• Update a field on a ticket's Topic works as a person's change does: the topic's SLA targets apply, keeping the time already used. A workflow for one department offers only that department's topics; a topic from another department is skipped with the reason.
• Reply to the requester. Write the reply; it can use variables, filled in for the requester (staff-only values stay blank). It's posted on the ticket as a public reply, signed by the person who built the workflow (built-in workflows by your district's assistant), and emailed to the requester like an agent's reply. When it's the ticket's first reply, it meets the first-response target of its SLA. Tickets with no requester are skipped.
• Set the status moves the device the way a person would, along the lifecycle its statuses' meanings allow (asset statuses): a retired device stays retired, and a change that isn't allowed is skipped with the reason. The change is on the device's timeline, signed with the workflow's name.
• Update a field can't change Department. Department is for filters only, because moving a record between departments changes who can see it. Assigning an asset takes it out of its cart or kit, and moving a cart moves what's in it, just as when a person does it.
• Notify in app. For people who work in schoolOS all day, like the IT team. Under Notify, add everyone who should hear it: The assignee, The requester (if staff) on tickets, specific people, and teams (everyone on them). Then write the message. It shows in their bell, grouped with that ticket's or task's other updates and signed Workflow: and the workflow's name, and pops up for anyone who has schoolOS open. Only people who can open the ticket or task get it: a requester only when they're staff who can open the ticket, and on a private ticket only the people on its list. The assignee is whoever has the record when the step runs, so an Update a field step above it that assigns the ticket is taken into account.
• Notify a person or team. Sends an Email, best for people who don't work in schoolOS all day, like a principal or a facilities supervisor on the move. Pick the recipient: a person on the record (The Requester, The Assignee), a person, or a team. Email needs a subject, and its body is written in the rich text editor: bold, lists and links, with variables where you type {{ or use Insert variable. On a restricted ticket, only people on its list get it. On assets and parts, it can send an In-app notification instead. Rules built before Notify in app that send in-app notifications about tickets or tasks keep working, and now show in the bell the same way.
• The assignee hears about what a workflow does. When a workflow assigns a ticket or task, the new assignee is notified (Workflow: Chromebook repairs assigned you a ticket). When it changes a field or a tag on one, its assignee is notified of the update. See Notifications.
• Reply to the requester. The requester reads it, so placeholders only staff see (like the staff link) aren't offered and can't be saved. On a private ticket the email says only that there's an update.
• Assign by location. Uses the teams set to cover locations in their department (Admin › Tickets › Teams). With Also assign a person on that team, it picks someone the team's own way (taking turns, or fewest open tickets); a team that assigns by hand takes turns. Skipped with the reason when no team covers the location.
• Add a task or checklist from a template and Send for approval add the template once per ticket, as a topic does: steps for the ticket's assignee or team wait until it has one, and due dates count from today. Send for approval only offers checklists with an approval step. A new or open ticket waits in Awaiting approval until they're decided.
• Add followers. On a private ticket, only people already on its list are added.
• Create a task. From a ticket, the task is linked to the ticket. From an asset, the task isn't linked to the asset, so put the asset tag in its name.
• Notify a person or team and Notify in app can also reach a group the record points at: on tickets, Department leads (the department's members who are admins) and Its team, else its department; on assets, Its school's techs (staff whose location is the device's school) and Asset admins.

Device actions#

The Jamf Pro actions, Google Devices actions and Intune actions groups appear when that service is connected, and work only on assets linked to one of its devices; other assets are skipped with the reason. Each is sent to the service in the background, so its step reads "queued", not "succeeded", and the device's timeline records it.

• Jamf Pro writes only on a Two-way connection. On a read-only one the group is grayed out, and a rule saved before is skipped with "Jamf Pro is connected read only, so workflows can't change devices."
• Turn on Lost Mode shows your lock screen message, an optional phone number and footnote. Lock the device takes an optional message. A Mac's unlock PIN, and the Set Recovery Lock password, are generated by schoolOS and kept on the device's timeline, where only people who can send device commands (Update assets) see them.
• Set a Jamf field writes one of Jamf's inventory fields, Copy from the asset or Use a fixed value. Update an annotated field does the same for Google's Annotated User, Annotated Location, Annotated Asset ID or Notes.
• Google Devices needs device management on. Deprovision asks for the reason Google records.
• Microsoft Intune needs device management on and approved in Microsoft; until then its group is grayed out, and a rule saved before is skipped with the reason. Each action works on the devices Microsoft supports it on (see Intune actions): Lost Mode, its sound and its location are for supervised iPads and iPhones, so a Windows laptop is skipped with "Enable Lost Mode is unavailable: Intune supports this on iOS/iPadOS, not Windows". Turn on Lost Mode takes the same message, phone number and footnote as Jamf's. Rename the device takes a name, which can be a variable such as {{asset.tag}} (the default). Wipe the device has Keep enrollment state and Keep user data, both off; a Mac's unlock PIN is generated by schoolOS and kept on the device's timeline. Intune confirms an action when the device next checks in, and the sync after that records it on the timeline.
• Erase the device, Wipe users, Powerwash, Deprovision, Intune's Retire and Wipe the device can't be undone, so the workflow asks first and they run only when the person who made the change types the confirmation.

Wait#

Wait pauses the workflow for an amount of minutes, hours or days (up to 30 days), then runs the steps after it. When the time is up, schoolOS looks at the record again: the steps run on the record as it is then, and only if it still matches the workflow's filters ("Status kind changed to Lost" still holds only if the device is still lost). If the workflow was edited, turned off or deleted in the meantime, the rest doesn't run, and the run history says why. A wait survives restarts and updates. It needs database migration 423; until then a Wait step stops the workflow there, with the reason.

Open a ticket about this device#

Settings: Subject and Description (with variables like {{asset.tag}}), the department and topic (IT and no topic unless you pick), Assign by the device's location, If the device already has an open ticket (Add to it, the default; Open another anyway; or Skip), the Reuse window in hours (24 by default), and Tell the ticket's assignee in schoolOS when the device is added (on by default).

The device's open ticket (not solved or closed) is found in this order:

1. One it's linked to.
2. One that mentions its asset tag or serial number as a whole word, in its subject, description, or any reply or note. Case doesn't matter, and LIN-0042 doesn't match LIN-00421. The device is linked to it, with the internal note "Linked to LIN-0042 because the ticket mentions it."
3. One its person opened. When the person the device is assigned to opened a ticket in the last 7 days, and it's their only open ticket that could be about a device (no other device linked to it, and in a device topic like Devices, or naming a device the way Otto's triage reads one, like "my Chromebook"), the device is added, with the note "Added because Sam Rivera, who has LIN-0042, opened this ticket."
4. Otherwise (no candidate, or more than one), a new ticket, with the device linked. When there were several candidates, it gets the note "Possibly related: #A, #B".

Add to it posts an internal note, "Damaged device workflow: LIN-0042 was set to Damaged by Pat Lee, Oct 21, 2026, 2:14 PM", links the device if it isn't, and tells the ticket's assignee in the bell if you left that on. It never emails the requester and never changes the ticket's status, assignee or priority. Within the Reuse window, the workflow never opens a second ticket for the device, even if the first was solved: it adds to that one. The device's timeline says what happened: "Ticket #812 opened by workflow Damaged device" or "Added to ticket #812 (the ticket mentions it)". A person linking a device to a ticket by hand puts "Linked to ticket #812" on the device's timeline too.

Select Create workflow to save, or Save changes when editing. If something is missing or invalid, the message says which step and why.

Run history#

Select the history icon on a workflow's row. You see its 25 most recent runs, newest first. Each run shows:

• Its result: Succeeded, Failed, Skipped or Matched (still running).
• The record type and event, like Ticket created, and when it happened.
• Each step: Conditions first, then each action with its result.

A run is recorded every time the trigger fires, even when the filters don't match. Those runs read Skipped, with the Conditions step skipped. That's normal: it tells you the rule saw the change and chose not to act.

Scheduled workflows are different: they record a run only for records that match the filters, so the history isn't filled with every record that was checked and passed over. Their event reads like Asset untouched, Ticket open for a while, Ticket with no reply from us or Ticket on schedule.

A Failed run says One or more actions failed. The other actions in it still ran, so check which step failed before you fix and rerun anything by hand. A skipped action doesn't fail the run: it means the action didn't apply, like a Google action on an asset with no linked device.

Otto can answer questions like "Which workflows failed this week?", and it suggests that one by itself when there are failures. See what Otto suggests.

Problems with a workflow#

A rule can break after you save it: someone deletes a field it uses, or removes a dropdown value it matches. schoolOS checks each rule against your account's current fields.

• A red badge ("1 problem") means the rule won't run correctly. For example, a filter on a deleted field never matches, and an action that writes to one fails.
• An amber badge ("Check filters") means part of it won't work as you might expect, like a value that no longer exists, or a filter that runs on every save.

Open the workflow to see the full reasons at the top of the builder, with the step each one is in. Fix the step and save.