Platform & Insights

Administration & Security

Role-based access control, user setup and password policy.

Overview

In most school software, "admin password" is the security model — shared logins, no trail, and a prayer. Administration & Security in ez.school is the governance layer institutions of standing require: role-based access with per-user overrides, activity and audit logs across every module, and password and session policy under your control.

  • Built-in roles & 80+ granular permissions
  • Per-user permission overrides
  • User setup & profile linking
  • Password policy & forced reset
  • Audit trails & session control
Case study · Security & Access

From one shared password to an answerable trail

Representative scenario — illustrative

A well-regarded 1,600-student school runs its office software on a single “admin” login that half the staff room knows, because setting up individual users was “too much bother”.

Doing it by hand

When marks were changed after publication, or a bonafide was issued to a student who had left, nobody could say who did it — the login was “admin”, and admin was everyone. A departing accountant’s access lived on for months because no one remembered to disable a password only a person, not an account, ever had. Reviews turned into arguments, because there was nothing on the record to settle them.

The cheap-ERP trap

The cheap ERP technically supported users, but every real role needed a workaround — the fee desk could see student marks, the class teacher could see other sections — so the school gave up and shared one powerful login again. There was no meaningful audit trail, no per-user override, no session or password policy. Six months in, “security” was still one password on a sticky note under the keyboard.

With ez.school

ez.school makes governance the way the platform works, not a feature you switch on. Roles match responsibility with per-user overrides for the genuine exceptions, so the fee desk sees fees and a class teacher sees their sections. Every consequential action — publishing results, issuing certificates, changing a role, unlocking marks — is logged with who, when and what, and password, session and sign-in policy are yours to set. Disputes end with a query, not a quarrel.

The difference, side by side
By handOrdinary ERPez.school
Who logs inOne shared “admin”Roles that don’t fitPer-person, role + overrides
Who did itUnknowableNo real trailActor, time and action logged
Leaver accessLives on for monthsManual, forgottenProvisioned and revoked per user
A disputeEnds in argumentNothing to checkSettled by the audit log
The outcome
  • Per userAccess provisioned
  • Every actionOn the record
  • YoursPassword & session policy

The activity trail — every result publish, certificate issue and role change carries who, when and what, so a review is a query not a quarrel.

Inside the app

How Administration & Security works for you

Access that matches responsibility

Roles define what each kind of user may see and do; per-user overrides handle the exceptions without inventing fake roles. A class teacher sees their sections, the fee desk sees fees — nobody swims in screens irrelevant to their duty.

Every consequential action, on the record

Publishing results, issuing certificates, changing a role, unlocking marks — logged with who, when and what. The audit trail is not a feature you enable; it is how the platform works. Reviews and disputes end with a query, not a quarrel.

The cycle

The governance loop

  1. 1Roles defined
  2. 2Users provisioned
  3. 3Actions logged
  4. 4Reviews read the trail
  5. 5Policy tightens
Who uses it

One app, seen from every seat

AdministratorProvisions a new teacher in minutes with exactly the right access.
Security reviewerFinds RBAC, audit and session policy laid out the way reviews ask.
PrincipalKnows who changed what — before a dispute becomes a drama.
Evaluation questions

Administration & Security — asked and answered

Can permissions be tailored per user?

Yes. Role-based access plus per-user overrides — grants and denials — so exceptions are explicit and audited rather than solved with shared logins.

What lands in the audit log?

Consequential actions across modules — sign-ins, role changes, publications, issuances, unlocks, edits to governed records — with actor, timestamp and context.

Do you support password and session policy?

Yes. Password rules, expiry and session controls are configurable; failed sign-ins are rate-limited.

Bring Administration & Security to your campus

Guided onboarding, local-currency pricing, and human support from day one.