Schedules and calling flows

Most flows start when a ticket, repair or person changes. This page covers the other ways a flow starts, and the steps that repeat work or hand it to another flow:

Trigger or step	What it does
On a schedule	Runs at a set time, once, or once for each record in a list
Something happened	Runs when a desk event or a connected app’s event occurs
Another flow calls it	A small flow other flows reuse, with inputs and results
For each (step)	Repeats the steps inside it for every item of a list
Call a flow (step)	Runs a flow that can be called, and uses what it hands back

For Another app calls it, see external flows and hooks.

On a schedule

Choose On a schedule as the trigger, then How often:

How often	You also choose
Every day	The time
Every week	The day of the week
Every fortnight	The day of the week. Every other week, counted from the first week of term inside a term
Every month	Day of the month, 28 at most so every month has it
Every term	Days into the term, where 0 is the first day of term
Every year	The Month and the day

At is in your school’s time, and 7:00 am stays 7:00 am across daylight saving. The flow reads as a sentence on its card, such as “Every Monday at 7:00 am” or “On 20 January every year at 7:00 am”.

Your school’s time and term dates

The timezone and open days come from Admin, Service levels (Timezone and Open days). If that calendar has never been saved, the server’s own timezone is used. Set it before relying on a schedule.
Term dates come from Costs, Reporting periods. An Every term schedule never runs if no term dates are recorded.

Only on school days

Only on school days is offered for Every day, Every month and Every year.

A daily schedule skips days that are not school days.
A monthly or yearly one that lands on a closed day runs on the next school day instead, once.

A school day is an open day that falls inside a recorded term. If no terms are recorded for that year, every open day counts. Public holidays inside a term are not known, so they count as school days.

A missed occurrence

Plugboard checks schedules every minute and claims each occurrence once, so two servers never both start it. If the server was down when a schedule was due, the most recent missed occurrence still runs if it was due within the last 6 hours. Anything older is skipped. Turning a flow on after its time that day does not start that day’s run.

A flow in Watching records what each occurrence would have done instead of doing it. Pause all flows stops schedules too.

For each record in a list

Under For each record, tick Run once for each record in a list. Each record becomes its own run, so one can be stopped without the others.

Setting	What it does
The list	A report dataset: tickets, repairs, devices, loans or people
Only records where	Up to 10 filters, each is one of or is not one of some values
At most	How many records one occurrence may start. 50 unless you change it, 200 at most

For example, “On 1 December every year at 7:00 am, for each person whose Year level is 6”. People filters include Type, Year level, Tutor group, Campus, Department and Active. The people list includes families as well as students and staff, so filter on Type when you mean one of them.

If more records match than At most allows, nothing runs. You get a sticky alert (“found 240 records and takes at most 200 at a time, so it started none”) and an audit entry, so a wrong filter can never start hundreds of runs. Narrow the filters or raise the limit; the next occurrence tries again.

Plugboard reads up to 5,000 rows of the dataset and filters those. For tickets, repairs, devices and loans these are the most recent; for people, the first 5,000 by last name. Keep lists well under that with filters.

The owner’s live access

The list is read with the flow owner’s access as it is on the day, inside the flow’s campuses, and for tickets inside the flow’s desk. If the owner leaves or loses the permission to read that dataset (for example client.view for people), the flow starts nothing and pauses, saying someone who can read it should take it over. If the dataset’s module is off, nothing starts.

Something happened

Choose Something happened, then pick an event. The picker is searchable and grouped, and greys out what your school cannot produce, with the reason.

Group	Events
Loans	Lent out, comes back, goes overdue, a loan device is added
Visitors	Signs in, signs out, a contractor’s check is about to expire
Stock	Counted or adjusted, sold or handed out, a repair part runs low
Kiosks	Someone asks at a kiosk, a kiosk request is dealt with
Devices	Enrolled or added, retired, changes hands, erased, device management stops syncing
Repairs	A vendor sends an update, the device is replaced, an insurance claim is lodged
Operations	Work is added, work changes status, a project changes status
Knowledge	A document is published, a document is due for review
Approvals	An approval is decided
Monitoring	A monitor goes down or comes back up, Plugboard’s backup fails or finishes
Security	A security alert is raised, a security incident is opened, someone asks to run blocked software, a backup job fails, a software request is approved or denied, someone activates Global Administrator

Under What it carries, each event offers its details as values for later steps.

Events from connected apps

Security alerts and incidents, blocked software requests and backup jobs come from connected apps (your security, application control and backup connectors). Plugboard asks those apps for anything since it last looked, every 5 minutes, but only while an on or watching flow listens for that event.

The first look is silent: it notes where the list is and starts nothing, so connecting a flow does not replay months of old alerts.
Each item starts one run, never two.
What another app says is untrusted. It can be shown, tested and sent on, but it never chooses who or what a step changes without a person.

The storm pause

A flow that starts more than 20 runs in 5 minutes is paused, “in case something is looping”, with a sticky alert and an audit entry. A school’s first device sync can do this to a flow listening for enrolled devices. To resume it, publish it again with Publish and turn on, which needs flow.publish and step-up and makes you its owner. Built-in flows and schedule lists are exempt.

Flows do not start each other by default. Can be started by changes other flows make, in a flow’s settings, lets changes made by another flow start it, up to three links deep and once per flow in a chain.

Every flow also counts toward the school’s hourly limits (60 runs of each flow and 500 for the whole school by default, in Flow controls, Hourly limits). A step over a limit waits and tries again in 15 minutes; it is never lost.

For each step

Add For each and choose The list: a list from the trigger or an earlier step, such as the groups a Build the account from a template step worked out. Steps inside its lane run once for each item, in order. Inside them, “Each: groups in the cloud” (or whatever the list holds) is the item it is on, and keeps the list’s origin.

At most: 50 unless you change it, 200 at most. If the list is longer, the step does nothing for any item, and the run stops and asks a person, so nothing runs for half of it.
One level only: a For each cannot sit inside another.
A step that fails follows its own If this fails for that item.

The run’s timeline says where it is, such as “3 of 12: Science Staff”.

Another flow calls it

Choose Another flow calls it to make a small flow others reuse, such as “Set up a staff laptop”. It must be on to be called.

Setting	What it does
It runs on	Nothing in particular, or a ticket, repair, person, device or loan device
What it is given	Up to 12 inputs. The calling flow must give it makes one required
It chooses who or what a step changes	Marks an input that picks a target
What it hands back	Up to 12 results, worked out when it finishes

An input marked as choosing a target only takes a record, the calling flow’s own setting or a staff member, never text someone typed or another app sent. That is checked when the caller publishes and again when it runs. Other inputs are treated as “From another app” inside the called flow.

The Call a flow step

Add Call a flow and choose Flow to call from the flows marked callable and turned on.

Run it on: when the called flow is about a different kind of record, choose which one, from the trigger or a step that found it. Otherwise it runs on this flow’s own record. A record matched from text asks for a go-ahead before the call.
What it is given: fill each input from the trigger or earlier steps.
Then: Wait for it to finish (later steps can use what it hands back) or Carry on at once.

Calls go three flows deep at most. Publishing the calling flow needs everything the called flow can do: its permissions and tiers are added to the caller’s, so nobody can reach a change through a called flow that they could not publish themselves. The called flow runs within its own owner’s authority.