Who Can See What
Access control, end to end: composing a role out of the platform’s own actions, granting it to a person for a fixed window, the sidebar and the pages that change as a result, the trail that records every use — including the refusals — and what a school sees when our own support staff need to look.
The question a school asks before any feature question
A school holds the most sensitive records most families ever hand over: a child’s medical notes, a family’s finances, a safeguarding concern, a staff disciplinary case. So the first serious question about any system is not what it can do — it is who in the building can open what, whether the answer survives contact with a real staff structure, and whether anybody could prove it afterwards. This walkthrough answers all three on the actual screens. It starts where permissions are composed, follows one grant to the person who receives it, shows the same product looking different in their hands because of it, and ends on the record — the trail, the refusals it keeps, and the strip across the top of the page that appears when the person reading a school’s records works for us.
On this page
A role is a sentence, not a tier
Most systems ship three or four fixed roles and ask a school to file itself under one of them. Real schools do not fit: the bursar who also runs the school store, the deputy head who covers a form class, the librarian who is trusted with attendance and nothing else. Here a role is composed from the same action catalogue the platform enforces against — so what you can describe is exactly what the system can be asked to allow, and nothing is approximated.
Every role the school can grant, in one register
Roles that ship with the platform and roles the school composed itself sit in one list, marked as what they are. The system ones are preview-only — they are the vocabulary the product itself is built on and a school cannot quietly widen them; everything a school builds is its own to change.
What a role actually grants, in words
Opening the Bursar shows the role as its clauses — a service, the specific actions inside it, and how far each reaches. This is the whole role, not a summary of it: the third clause is the honest one, because it says that a bursar may read a pupil’s name and guardian, and nothing else about the child.
Composing one, clause by clause
A blank role is a title and a first sentence. Add a clause, pick the service it is about, tick the operations inside it, and choose how far it reaches. Nothing here is free text and nothing is invented: every option is an action the platform’s own guard will be asked about at request time.
Ready to run your school on this?
Every screen in “A role is a sentence, not a tier” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Giving it to a person, and for how long
Composing a role changes nothing on its own. Access begins when a role is granted to a person, and the thing that goes wrong in every school is not the grant — it is the ungrant. The cover teacher goes back to their own class in January and keeps the form teacher’s reach until somebody remembers. So a grant here can carry its own end date, and the register keeps the ones that have ended.
The register of who holds what
One row per grant, per person: the role, whether it is permanent or dated, whether it is running yet, and the reason it was given. A revoked grant stays on the register, because revoking is not deleting and “who used to be able to do this” is a question schools are asked.
One grant: a person, a role, a window, a reason
The form is deliberately four decisions, and the fourth is the one most systems leave out. A reason turns the register into something a governor can read a year later without having to reconstruct what the school was thinking in September.
Access as a thing you can watch, not just set
The reporting side of the same record: how many people hold each role, which grants are about to expire, and how the shape of access has moved over the term. A school that has been running for three years has drift, and drift is only visible in aggregate.
See this on your own school’s data.
Every screen in “Giving it to a person, and for how long” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
The sidebar is the permission
Here is the part that cannot be shown from the administrator’s chair, and it is the part that matters: what the product looks like to somebody who has not been granted anything. Samuel is a member of staff at this school. Every employee gets this much on the day they are created, and until a role says otherwise, this is the whole product.
Everything an employee gets for existing
His own workspace: his day, his calendar, his payslips and invoices, his leave, his messages, his own record. No pupils, no classes, no finance, no clinic — not hidden behind a locked icon, not there at all. A permission he does not hold is not an upsell wall; it is an absence.
Set this up for your team.
Every screen in “The sidebar is the permission” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
One grant later
Tunde holds the same staff account as Samuel, plus one thing: the Librarian role. That single grant is the entire difference between the previous screen and this one — a School HQ section appeared in his sidebar, and behind it is the library desk. He did not get a different app, a different login, or a seat upgrade.
The desk the role opened
Issuing, returns, renewals, overdues — the library module’s own circulation screen, opened by an ordinary employee whose role happens to include it. His self-service is still there below it, unchanged, because he is still a member of staff first.
Ready to run your school on this?
Every screen in “One grant later” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
The two accounts no role describes
Roles answer “what may this employee do”. They are the wrong shape for the two largest groups of accounts a school has, because a parent’s reach is not a job — it is a relationship, and a pupil’s reach is themselves. Neither is granted by anybody, and neither can be widened by asking the system differently.
A guardian sees their children, and the set is the boundary
Ngozi is linked to two pupils, so her portal is about two pupils. There is no filter that widens it, no ward picker that lists the school, and no address she can type that reaches a third child — because the link between guardian and ward is the scope, applied where the data is read rather than where the page is drawn.
See this on your own school’s data.
Every screen in “The two accounts no role describes” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Everything it did — including what it was refused
Access control that cannot be inspected afterwards is a policy, not a control. The trail records consequential actions with who did them, what they touched and how it turned out — and it keeps the attempts that were denied, which is the half most systems discard and the only half that tells you a boundary is being tested.
The trail, in a school’s own words
Sentences, not identifiers. No resource types, no action codes and no opaque ids on the face of the page — the row reads as what happened, with the people and records it names resolved to their names. The technical rendering is still there, one click down, for the day somebody needs to trace a call.
A refusal, expanded
This row is a subject teacher opening a pupil record for a class they do not teach. It failed, and it is on the record with the reason it failed — the role’s own reach. A trail that only holds successes cannot tell you the difference between a system nobody is testing and a system whose boundaries are being probed.
The shape of activity, not just the list
Volume over time, denied actions, the most active accounts. A single denial is a mistyped address; forty from one account on a Sunday night is a conversation the school needs to have on Monday, and only the aggregate makes that visible.
Set this up for your team.
Every screen in “Everything it did — including what it was refused” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
And when the people looking are us
Support work sometimes needs to see what a school sees. Every hosted system has this capability and most never mention it, which is the part schools object to when they find out. So: our support staff can open a read-only session inside a school, it is approved rather than self-served, it expires, and — the part that belongs on this page — the school is told while it is happening and keeps the record afterwards.
The school is told, on every page, for as long as it is true
This is an ordinary pupil register. The strip above it is what a school sees for the whole duration of a support session: who is reading, which case it is for, that it is read-only, and how many minutes are left, counting down. It is not in a menu and it is not in a notification that can be missed — it sits above the navigation, so it cannot be scrolled away from.
And it is on the school’s own trail, not ours
The session opened at 14:05 is a row on the school’s audit trail, with the reason it was opened and the approval behind it — and so is every record read inside it. The rows are attributed to a named person at EaseAcademia, not to the school account the session borrowed, which is the distinction that makes the record worth keeping.
Ready to run your school on this?
Every screen in “And when the people looking are us” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Run your whole school on one connected platform
Start with the base package, switch on the modules you need, and give every parent, student and staff member a single place to log in.