Roles

This page is for anyone trying to work out who can do what across PTRS, or puzzling over why a screen let someone in and then refused every action on it.

What actually decides access

Two separate systems decide this, and neither is built from the other.

PTRS's own server keeps 22 named rules, each one a plain list of roles. The screens keep a much rougher map of their own: four broad groups, plus a separate one for guardians. Nothing generates one from the other, so what a screen offers and what the server actually allows can disagree. Where they do, the server always wins: the button is there, and the attempt behind it fails.

The menu applies no check of its own at all, so every signed-in account sees every menu entry. Whether a given screen actually works for that account is only discovered by opening it.

When a narrower rule sits on top of a broader one

This is the part that actually decides what a role can reach, and it is easy to get wrong by reading only the table further down this page.

Most parts of PTRS apply one rule to a whole group of related actions, and that is the end of the story. A handful apply a second, narrower rule on top of specific actions inside that group. When both apply, both have to be satisfied, so the rule that actually governs an action is the overlap between the two, never just the wider one.

Module	What is different
Programs	A rule sits on the whole group, and a second, narrower rule sits on top of almost every individual action, including the two reads every Programs screen depends on
Health & Safety	Five different rules are spread across its actions rather than one rule for the whole group
Incidents	A handful of actions carry a narrower rule than the group
Administration	The same shape, on a smaller scale
Members	The same shape, on a smaller scale
AI Assistant	A shared rule covers the group, and three regulation-library actions narrow it further
CACFP	A small number of actions narrow the group's rule
Analytics & Reports	The same, smaller still

Everywhere else in PTRS, one rule on the whole group is the entire story.

Two worked examples, both read directly from what PTRS actually enforces.

Loading a regulation document is one example. The AI Assistant's shared rule admits Staff and four other roles. Three regulation-library actions narrow that further, on top of the shared rule, to your organisation's super admin alone.

Rule	Admits
The shared AI Assistant rule	Staff, a site director, a regional director, an organisation administrator, a super admin
The regulation-library rule, added on top	A super admin
What actually applies	A super admin

Opening a program is a second example. The rule on the whole Programs group admits a site director, a regional director, an organisation administrator or a super admin. Thirteen of the module's own actions, including the two reads every Programs screen depends on, narrow that further with the member-management rule, which admits Staff and an organisation-wide administrator but not a regional director.

Rule	Admits
The rule on the whole Programs group	A site director, a regional director, an organisation administrator, a super admin
The member-management rule, added on top of most individual actions	Staff, a site director, an organisation administrator, a super admin
What actually applies	A site director, an organisation administrator, a super admin

So a regional director cannot list or open a single program, even though the rule on the group itself, the one whose name matches the module, would seem to admit them. Reading only that one rule would say the opposite of what actually happens. The full, action-by-action detail lives on Programs core actions and Programs delivery actions.

Reading the table further down this page alone can therefore overstate what a role actually reaches. Each task page in this documentation names the specific rule that governs its own action and states the outcome that actually applies, and that page is always the authority, not this one.

What this page used to say

An earlier version of this page said that one rule always covers a whole group of actions, with no separate rule for reading versus changing anything, outside Health & Safety. That was true of most of PTRS and wrong about several modules, Programs most of all, the largest module in the whole product. Corrected against the actual server code.

The eight role names

Seven sit in a ranked order, lowest to highest: read-only, guardian, Staff, site director, regional director, organisation administrator, super admin.

An eighth, an OCCL auditor, is named by two rules and exists nowhere else in PTRS. See the two roles with no working experience below.

Which rule admits which role

Read in the order PTRS itself declares them.

Rule	What it protects	Who it admits
The everyday visibility rule	Seeing organisation-wide figures, such as the dashboard and ratio readings	Staff, a site director, a regional director, an organisation administrator, a super admin
The site-management rule	Creating and changing a site's own record	A site director, an organisation administrator, a super admin
The incident-filing rule	Filing and working an incident	Staff, a site director, an organisation administrator, a super admin
The staff-management rule	Managing the staff directory	A site director, an organisation administrator, a super admin
The reporting rule	Reports and the audit trail	A site director, a regional director, an organisation administrator, a super admin
The member-management rule	Children's records, imports, and notes	Staff, a site director, an organisation administrator, a super admin
The AI Assistant rule	The chat and the plain-English data question screen	Staff, a site director, a regional director, an organisation administrator, a super admin
The Parent Portal rule	Every guardian screen	A guardian
The financial-data rule	Budgets and financial figures	An organisation administrator, a regional director, a super admin
The HR rule	Personnel files and sensitive staff records	An organisation administrator, a super admin
The staff self-service rule	A staff member's own record and schedule	Staff, a site director, an organisation administrator, a super admin
The OCCL audit rule	The OCCL-facing audit view	An OCCL auditor, an organisation administrator, a regional director, a super admin
The program-management rule	The whole Programs group	A site director, an organisation administrator, a regional director, a super admin
The charter-approval rule	Approving a program's charter	An organisation administrator, a regional director, a super admin
The regulation-library rule	Loading and removing regulation documents	A super admin
The health-data viewing rule	Reading health and safety records	Staff, a site director, a regional director, an organisation administrator, a super admin
The health-data management rule	Changing health and safety records	A site director, an organisation administrator, a super admin
The medication-log rule	The medication administration log	Staff, a site director, an organisation administrator, a super admin
The emergency-plans rule	Emergency action plans	Staff, a site director, an organisation administrator, a super admin
The OCCL audit status rule	The OCCL-facing health status view	An OCCL auditor, an organisation administrator, a regional director, a super admin
The user-management rule	Inviting and managing accounts	An organisation administrator, a super admin
The top-level account rule	The narrowest rule in PTRS	A super admin alone

A read-only account satisfies none of these.

Where to find the rule for a given task

Every module in PTRS is documented, and each task page names the rule that governs its own action, alongside the screen's own check and any place the two disagree.

Start from a module's own overview page and open the task you need. Each module's reference page for who-can-do-what lists every action in that module with the rule behind it, for example who can do what with incidents or Programs core actions. The flows trace work that crosses several modules, and each step links to the page that names its own rule.

Two roles with no working experience behind them

A read-only account satisfies none of the 22 rules. It is given organisation-wide visibility at the broadest level and then refused by every one of them, so an account like this can be scoped to see the whole organisation and still open nothing in it. There is no working read-only experience to document, because none exists.

An OCCL auditor is worse off than simply sitting outside the ranked order; it does not exist as a role PTRS can actually assign. Two rules name it, and nothing else in PTRS does.

Neither of PTRS's own sign-in environments defines this role at all; each one declares only the seven roles in the ranked order above, and an OCCL auditor is not among them. PTRS's own internal list of roles omits it too, so PTRS cannot even recognise the name if it saw it, and the screen that offers roles to assign filters from that same list, so it can never be offered there either.

So an account holding this role cannot be created through PTRS at all, and even one created directly through the sign-in service would still find that the broader of its two rules is never actually applied to anything. There is no working auditor experience to document, because none exists.

Both are gaps in the product, recorded for the team responsible for it. Documenting a workflow for either would describe an experience nobody can actually have, so neither is documented until the gaps are addressed.

Where the two systems visibly disagree

The screens' own reporting group admits a read-only account. The server's reporting rule does not. So reporting is offered to a read-only account and then refused the moment it is actually used.

Every task page in this documentation states the outcome you will actually experience, not what the screen implies before you try.

Per-role task lists

Not written yet, and the last open item across this whole documentation site. Until they exist, use the role picker in the header to narrow the menu to your own role, and the flows to find work that crosses several modules.

The picker filters on each page's own declared audience, which is a judgement made while writing these pages. The rule actually named on each task page is the authority, not the picker.