Flows

A flow is something the desk does on its own: “when a ticket about a projector comes in, send it to the AV queue and tell the technician on duty”, or “when a staff member leaves, turn off their account, hand their mailbox to their manager, then remove their licences a month later”. Flows live at Flows in the Service desk group of the navigation, under the Automation module.

The parts of a flow

Part	What it is
Trigger (“When”)	The one thing that starts the flow, such as a ticket being raised or a person leaving
Conditions (“Only if”)	Optional checks on the record, joined by All of these or Any of these. A condition can be a field (“Category is Access”) or written in words (“the ticket is about a staff member starting at the school”)
Steps	What happens, in order, on one vertical list. Branches split into lanes side by side
Versions	Every publish makes a fixed, numbered version. Your edits stay in a draft until you publish again
Runs	One run is one go through one version for one record. A run keeps the version it started on
Subject	The record a run is about: a ticket, repair, person, device, loan, visit, stock item, kiosk, operations job, document or monitor. Schedules, alerts from other apps and calls from other apps can run about no one record

Each flow has an owner (the person accountable for it), a home desk and, optionally, the campuses it covers. A ticket or repair flow belongs to one desk and only sees that desk’s records.

What can start a flow

Trigger	When it fires
A ticket	It is raised, changes (status, priority, category, queue, assignee, campus or kind), gets a reply from the requester, goes late, sits untouched for a set time, or is resolved
A repair	It is lodged or changes status
A person	They join, move or leave in the people sync, are added in Plugboard, or their details change. Staff, students or both; never parents. See people flows
A request	Someone asks for a catalogue item that names this flow to fulfil it
Run by hand	Someone runs it from a ticket or a person’s page, or for themselves (such as asking for an admin role), with a short form if the flow has one
On a schedule	Every day, week, fortnight, month, term or year at a local time, optionally on school days only and once for each record in a report. See schedules
Another flow calls it	A small flow other flows reuse, with inputs and results
Something happened	A desk event (a loan goes overdue, a visitor signs in, a device enrols, a backup fails) or an event from a connected app (a security alert)
Another app calls it	Power Automate, Zapier or a script starts it with a token. See external flows and hooks

A change made by one flow does not start another flow unless that flow has Can be started by changes other flows make turned on in its settings. This stops two flows setting each other off in a loop.

The kinds of step

Step	What it does
Action	One thing from the action catalogue: change a ticket, lend a loan device, issue stock, add someone to a group, assign a licence, send an email or Teams message, lock a device, and more across tickets, repairs, loans, stock, visitors, kiosks, devices, operations, knowledge, people and your connected apps
Approval	Asks people to approve before the flow carries on. Approved, Declined and Expired each have their own lane, so a refusal can never fall through to the approved path
Go-ahead	One person checks what the next steps will change and lets them run
Task	Gives someone something to do, optionally with a form whose answers later steps can use
Hand to a technician	Brings a technician to a guarded screen, such as a password reset, with the person filled in
Wait	For a time, until a date from the record (“7 days before their start date, at 7:00 am”), or until something is true, with a time limit and a lane for when it runs out
Branch	Takes a different lane depending on the record. Lanes join up again below
Decide	Asks AI a question with set answers and follows the lane for the answer, with a Not sure lane. See decision models
Write with AI	A summary for the desk, or a reply draft, written as an internal note for a person to read. Nothing is sent by itself
For each	Repeats the steps inside it for every item of a list: 50 items by default, 200 at most
Call a flow	Runs another flow that can be called, and uses what it hands back. Calls go three deep at most
Start an external flow	Starts a Power Automate flow, a Zap, a Make scenario or an n8n workflow through a connection
Stop	Ends the run, as finished or stopped, with a reason

A flow holds at most 50 steps, branches nest two deep, and a run stops after 500 executed steps or 10 Decide steps.

Risk tiers and the go-ahead

Every action has a tier. The tier is part of the action, never something the author picks, and it decides who must be present.

Tier	Examples	How it runs
Reads only	Look up a device, read account state, find a person	On its own
Changes Plugboard records	Set ticket fields, assign, add a note, raise a ticket, lend a loan device	On its own
Sends a message	Email, Teams message, a reply to the requester	On its own, to people taken from records or the flow’s own settings
Changes another system	Add to a group, assign a licence, move an organisational unit, start a directory sync	After a go-ahead
Privileged change	Create, turn on or turn off an account, sign out everywhere, mailbox access, lock a device, admin role activation	After a go-ahead with step-up

A go-ahead goes to someone who holds every permission the covered steps need. It shows what each step will change and freezes it: if the record changes before the step runs, the go-ahead is asked again. A step can ask for more than its tier needs (for example, a go-ahead before an email), never less.

Some people can never give a go-ahead for a step: the person the step acts on, and the requester. Temporary access never counts towards one. A ticket that arrived by email says so on the go-ahead card (“the sender is not verified”).

Who a run acts as

A run never acts with more authority than a person. Each step re-reads that person’s access when it runs, so a step scheduled for next month runs under next month’s access, or not at all.

Run by hand: each step acts as the person who pressed Run. A step they cannot do themselves asks someone who can for a go-ahead.
After a go-ahead or approval: the covered steps act as the person who gave it.
Everything else: the flow acts within its owner’s live access, campus and desk. If the owner loses a permission the flow needs, or leaves, the flow pauses and says so until someone with that access takes ownership.

The run timeline shows who each step acted as.

Caps, storms and pausing

Hourly limits. Each flow may run 60 steps that change or send something an hour, and the whole school 500, unless an administrator changes them in Flow controls. A step over a limit waits and tries again later; it is never lost.
Storm pause. A flow that starts more than 20 runs in 5 minutes pauses itself, in case something is looping, and raises an alert.
Pause all flows. One switch in Flow controls stops every flow at once: nothing starts and runs in progress wait where they are until it is turned off.

What flows never run

A flow can never erase a device, read a local administrator password, reset a password or MFA, change Conditional Access, delete anything, change Plugboard roles, permissions, API keys, connectors or sign-in settings, or edit or publish a flow. Plugboard refuses to start if any action breaks this rule.

Wipe, local admin password, MFA and password resets stay on their own guarded screens, with their own typed confirmations and step-up. A flow reaches them with Hand to a technician: a task whose button opens that screen with the person or device filled in. The flow brings the right person to the control; it never presses it.

Groups that grant administrative rights, and accounts that hold a directory role or match the school’s protected list (break-glass and service accounts), are refused by every account step. See Building a flow.

Permissions

Permission	What it allows
`flow.view`	See flows, versions and runs, and the Flows panel on tickets, repairs and people
`flow.build`	Draft, edit, duplicate and test flows, use the drafting chat and templates, and ask someone to publish
`flow.publish`	Publish, turn on or off, restore a version, change the owner, and use Flow controls

To publish, you also need every permission the flow’s steps use, because a published flow acts on its own. Publishing, restoring, turning on and taking ownership ask for step-up. Built-in roles that hold workflow.manage hold all three; built-in roles that hold ticket.view hold flow.view. flow.publish can never be granted through temporary access. See permissions.

On the public demo

The public demo can build, test and publish flows, and run steps that change Plugboard records on demo data. Anything that would leave the building (emails, messages, other apps, inbound hooks, connections and external flows) is refused, and the form says so before you fill it in. Privileged steps show as not available there.

Audit

Every change to a flow is in the audit log: drafts saved, publishes (with the version and who published), status changes and automatic pauses with their reason, ownership offers and changes, restores, question changes, Flow controls changes, go-aheads, declines, skips, retries, undos, cancelled runs and runs started by hand. Changes a step makes to a ticket or an account keep their own audit rows, naming the flow and the run.