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.
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.
Checked against PTRS on 7 September 2026.