People flows
A people flow is a flow about a person. When someone joins, moves or leaves in your student system, or is added or edited in Plugboard, a people flow can build their account from an account template, create it in Active Directory, Entra ID or Google Workspace, sync it, assign licences and groups, hand their mailbox to a manager, and recover their devices. Nothing changes an account until someone gives the go-ahead, and nothing a flow does is ever a delete.
Start from a gallery template rather than a blank flow. For how flows are built, tested and published in general, see the flows overview and building a flow.
What starts a people flow
Section titled “What starts a people flow”| Trigger | Starts when |
|---|---|
| A person joins, moves or leaves | The people sync or Plugboard reports one of Joins, Moves, Leaves, Added in Plugboard or Details change |
| Run by hand, On a person | Someone presses Run a flow on a person’s page, such as for a leaver who left early |
| Run by hand, For themselves | Someone runs it for themselves, such as asking for an admin role |
| Someone asks for it from the catalogue | A request type in Admin, Access & requests names this flow to fulfil it |
For a person trigger, choose Who: Staff, Students or both. Parents never start a flow. For Details change, you can limit it to some fields under Only when one of these changes (kind of person, year level, tutor group, campus, department, position, start date, leaving date, manager or email).
A flow run by hand on a person can ask questions first (Run form). The answers are marked as entered by staff. Each step then checks what the person who pressed Run may do.
Staff details the flows use
Section titled “Staff details the flows use”Joiner and leaver flows lean on start date, leaving date, department,
position, manager and preferred name. Plugboard takes these from Sentral,
TASS, Synergetic, OneRoster, Compass and Edumate where each sends them. A field
the student system does not send can be filled in on the person’s Staff
details panel (needs client.manage); a field it does send shows where it
came from and cannot be edited in Plugboard. See people.
The details gate
Section titled “The details gate”A joiner’s record often arrives before their start date, department or manager is known. Under Before it acts, tick Wait until we know their details and choose Details it needs. A run with something missing waits instead of acting on half a record:
- The run waits as Waiting for details, and checks again after every people sync, every edit to the person and at least hourly.
- After Ask a person after days (3 unless you change it, 0 to ask straight away), it puts a task on the run’s case ticket asking for exactly what is missing, as a form.
- The answers are kept on the run with the name of whoever gave them. They are not written back to the person’s record.
- A run still waiting after 30 days stops and says so. Nothing was changed.
The details you can require are first name, last name, preferred name, email, start date, leaving date, campus, department, position, manager, year level, tutor group and student system id. A dry run says which details it would wait for.
Case tickets
Section titled “Case tickets”A people run opens one case ticket the first time it needs somebody: a go-ahead, a task, the details question or a sign-in. It is a service request in your desk’s queue, titled with the flow and the person (for example “Staff leaver: Sam Lee, leaves 3 Feb”), and holds the run’s go-aheads, approvals and tasks. The run’s timeline is in its Flows section.
Until then, the run header says “A case ticket opens when someone is first asked”. Open a case ticket when someone is needed is on by default for people flows; with it off, the flow cannot ask anybody anything.
Account templates
Section titled “Account templates”Admin, Account templates (/admin/account-templates). Viewing needs
directory.view; creating and editing need directory.manage.
An account template says what account a kind of person gets. The Build the account from a template step uses the template that fits the person best, or the one you name.
| Section | What it holds |
|---|---|
| Applies to | Staff or students, campuses, year levels, departments, positions. Rank breaks a tie (lower wins) |
| Where it goes | The directory, and the organisational unit (an AD path such as OU=Staff,OU={campus.code},OU=School Users,DC=school,DC=internal, or a Google path such as /Staff/{campus}). Cloud-only Entra accounts have none |
| Names | Usernames, tried in order, the email and display name patterns, Longest username and Hyphenated names |
| First sign-in | How they first sign in, and When the account can be used (When it is made or On their start date, at a time) |
| Attributes | Each attribute either A fixed value or From the student system |
| Access by rule | Rows of “when … add …”: groups and licences from the access catalogue |
Naming rules
Section titled “Naming rules”Username patterns use {first}, {first1} (first initial), {last},
{preferred} and {n}, and are tried in order, such as {first}.{last},
then {first1}{last}, then {first}.{last}{n}. {n} counts from 2. Accents
become plain letters, and apostrophes and spaces are left out. A name longer
than Longest username (20 by default, the Active Directory limit) loses
letters from the last name first.
Collisions
Section titled “Collisions”Every candidate is checked against every connected directory, Plugboard’s own people, reserved names (admin, administrator, it, principal, root, helpdesk, support, info, office, plus your own list) and anyone who left in the last 12 months, because addresses are not reused for a year. The first free candidate wins. If a directory cannot answer, the name is not chosen at all.
Access, managers and passwords
Section titled “Access, managers and passwords”- Groups are labelled Active Directory group (added in AD before the sync) or Cloud group (added in Entra or Google once the account appears).
- Groups a connector refuses (groups that grant admin rights, role-assignable, dynamic, mail-enabled or synced from AD when the account is cloud-side) are shown as Refused, with the reason, and cannot be chosen.
- Licences show the seats left.
- Suggest from existing staff proposes rows from what current staff in that department hold, as shares, never names.
- The manager comes from the roster’s manager field, never typed.
- Plugboard never sees or stores a password. The first sign-in is a random password nobody sees that must be changed (a technician sets the first password at hand-over), a temporary access pass for Entra given only to their manager or the ICT lead, or an initial password for Google delivered the same way.
Checking it against a real person
Section titled “Checking it against a real person”Beside the editor, a live panel shows the account the template would make for a real person: pick anyone, or one of the Joiners waiting in a flow. It shows the username and why other candidates were passed over, the email, place and attributes with where each came from, the groups and licences, how they first sign in, and anything missing. Nothing is created.
Identity actions
Section titled “Identity actions”| Action | Tier | Permissions | Undo |
|---|---|---|---|
| Build the account from a template | Reads only | directory.view |
|
| Create the account | Privileged | identity.account.manage, directory.manage |
Turns the account off |
| Add to groups, Remove from groups | Change | directory.manage |
The reverse |
| Assign licences, Remove licences | Change | identity.license.manage |
The reverse |
| Turn the account off, Turn the account on | Privileged | identity.account.manage (on also needs identity.account.enable) |
The reverse |
| Sign out everywhere | Privileged | identity.session.revoke |
None |
| Give mailbox access | Privileged | identity.mailbox.delegate, identity.mailbox.fullaccess |
Takes the access away |
| Move to an organisational unit | Change | directory.manage |
Moves it back |
| Set account details (usage location, department, job title) | Change | directory.manage |
Sets them back |
| Wait for the account to appear | Reads only | identity.view |
|
| Start a directory sync | Change | directory.manage |
|
| Set an automatic reply, Convert to a shared mailbox, Hide from the address book | Change | identity.account.manage |
Reply off and shown again; no undo for converting |
| Recover devices and loans | Changes Plugboard records | ticket.create |
|
| Activate the admin role | Privileged | identity.view |
See PIM |
Every identity write records its intent in the audit log before the call and its outcome after.
Active Directory over LDAPS
Section titled “Active Directory over LDAPS”Create the account, groups, enabling, OU moves and attributes in on-premises Active Directory run through the site agent on your network, over LDAPS only (plain LDAP is refused). The agent’s bind account should be delegated to create users in your users OU and manage the listed groups, never Domain Admins.
- If an account with the person’s employee id already exists, the step adopts it unchanged, so a re-run is safe.
- If the chosen name belongs to someone else, it refuses.
- Groups that grant admin rights, directly or through nesting, and accounts that hold admin rights are refused. So is an OU outside the configured users OU.
See Active Directory.
Directory sync, and waiting for the account
Section titled “Directory sync, and waiting for the account”Start a directory sync runs one fixed operation for the account:
| Sync | How |
|---|---|
| Microsoft Entra Connect Sync | The site agent on the sync server starts a delta sync. Its account must be in ADSyncOperators |
| Microsoft Entra Cloud Sync | Provisions that one account on demand through Microsoft Graph, by its AD name, so it goes after the account is created |
| Google Cloud Directory Sync | The site agent on the GCDS host runs your configured sync command and configuration file |
Wait for the account to appear then checks every 2 minutes (1 to 60) and gives up after 60 minutes (up to 24 hours). With Must be synced from Active Directory on, it only accepts the account that came from AD, with a source anchor matching the one it created, so a cloud account that happens to share the address is never mistaken for it. On timeout the run needs attention: retry to wait again, or hand it to a technician.
Leaver mailboxes are off until you turn them on
Section titled “Leaver mailboxes are off until you turn them on”Set an automatic reply, Convert to a shared mailbox and Hide from
the address book refuse until the school turns on the Microsoft Entra
connector setting that allows leaver mailbox changes
(allowLeaverMailboxChanges), after giving the app registration the reviewed
Exchange role. See Microsoft Entra ID.
The Staff leaver template converts the mailbox to shared before its licences are removed, so the mail is kept.
One go-ahead for the account steps
Section titled “One go-ahead for the account steps”A Go-ahead step covers every later step that needs one, up to the next go-ahead. One person checks what those steps will change, gives the go-ahead (with step-up when any covered step is Privileged), and the steps then run when they are due, as that person, with their access checked again each time.
- The go-ahead freezes what it approved, such as the built account’s name, place, groups and licences. If any of that changes before a step runs, it asks again.
- The person a step acts on can never give its go-ahead, whatever they hold.
- Pressing Run on a person counts as the go-ahead for the steps the presser could do themselves.
- Temporary access never counts: whether someone may give a go-ahead comes from their roles alone (see PIM and temporary access).
Go-ahead cards sit on the run’s timeline and its case ticket, and lead with what will change.
Batches from one roster sync
Section titled “Batches from one roster sync”When one people sync produces several joiners (or movers, or leavers) for the same flow, their runs form a batch. The People tab on Flows shows “12 joiners from one sync waiting for a go-ahead” with Review the group: untick anyone to leave out, then one go-ahead with step-up covers the rest. Each run still follows the normal go-ahead rules. Admin role runs are never batched.
The 20% roster cap
Section titled “The 20% roster cap”If a sync would make more than a fifth of your active people leave, nobody is
deactivated and holders of user.manage are alerted to check the export. Flows
apply the same rule per kind: if one sync reports more joiners, movers or
leavers than a fifth of your active people, no flow starts for any of them,
and holders of flow.view get a sticky alert. Fix the student system’s export
and sync again.
Every changed step offers Undo, and a run’s menu offers Undo this run. Undo needs a reason, the undo step’s own permissions, and step-up where the step was Privileged. Nobody can undo a change to their own account.
Undo never deletes. Undoing Create the account turns the account off. Undoing a run stops it and reverses its steps newest first, stopping at the first failure. Signing out, converting a mailbox, syncs and waits have no undo.
Protected accounts
Section titled “Protected accounts”Flows never change:
- an account that holds a directory role;
- an account listed under Accounts no flow may change;
- an account whose name contains one of the Names that protect an
account, by default
breakglass,break-glassandemergency.
Both lists are in Flow controls (the menu on /flows), under
Protected accounts. Saving needs flow.publish and step-up.
The People tab
Section titled “The People tab”The People tab on Flows (/flows?tab=people) lists people flow runs
under Joiners, Movers and Leavers, each with its open count, and
shows a batch waiting for a go-ahead above the list. It needs flow.view.
A person’s page also has a Flows panel listing their runs, with what happens next (“Asks someone for start date, manager Mon 5 Oct”), and Run a flow for flows run by hand on a person.
Leftovers
Section titled “Leftovers”Licences & access (under Knowledge & reports) has a Leftovers panel:
leavers who still hold a device, a loan, a licence or an enabled account 30
days after their leaver flow started. It needs directory.view and
identity.view. Leaver flows opens the People tab.
Access & requests
Section titled “Access & requests”Admin, Access & requests (/admin/access, needs directory.view)
holds the Access catalogue (the groups and licences people may ask for)
and Request types.
- A request type shows “Fulfilled by the flow ‘…’” and its state. If that flow is not on, people can still ask, but nothing happens until it is published.
- For group access, Remove after a number of days (off by default, 90 suggested, 1 to 365) sets a removal date on each request. The Group access request template waits until that date and takes the person out of the group again.
Gallery templates
Section titled “Gallery templates”| Template | What it does |
|---|---|
| New staff account | When a staff member joins with complete details: build, one go-ahead, create in AD, groups, sync, wait, licences, cloud groups, then hand-over |
| New student account | Build, go-ahead, create, licence and groups, then a technician hands over first sign-in |
| Staff leaver | At the end of their last day: go-ahead, turn off, sign out, automatic reply, shared mailbox, manager access, hide, recover devices; licences and groups a month later |
| Student leaver | Turn off, sign out, recover devices; licences and groups a month later |
| Year-level move | Work out their next year level’s groups from the template and swap them after a go-ahead |
| Group access request | Manager approves, go-ahead, add; removed again when the request type says so |
| Licence request | Manager approves, go-ahead, assign |
| Shared mailbox access | Manager approves, a technician gives access |
| Request an admin role | See PIM and temporary access |
| Device return | Raise a ticket for their devices and loans, and a task to check everything came back |
| New-starter kit | A few days before a staff member starts, a task to get their laptop and kit ready |
On the public demo, steps that change a directory or mailbox are unavailable; dry runs still work.