Four login types
Application Admin (our team), School Admin, Staff, and Parent. Each logs in the same way but lands on its own home screen — a parent sees only their own child, our team can never touch a school's fee money.
Admin & Security
Who can sign in, and exactly what each person is allowed to see and do. Four login types, a permission system that starts at zero and grants only what's needed, an audit trail on sensitive data, and a hard wall between every school's records.
What it does
Every person who touches the system signs in through one of four logins — our own team, the school admin, staff, and parents — and each one lands on a different home screen and sees only the data meant for them. Sign-in needs three things, not two: a school code, a username, and a password, so the same username can safely exist at two different schools.
Inside a school, the admin decides what each staff member can reach through a detailed permission matrix — nothing is allowed unless it's granted. Sensitive changes are recorded, and because every record is stamped with the school it belongs to, no school's data is ever visible to another.
Inside the module
Role-based permission matrix
A new staff login starts with zero access. The admin switches on exactly the modules and submodules they need — Attendance, Exams, Fees, and more — each with View and/or Edit. One-click templates (Teacher, Accountant, Principal) set sensible defaults.
Audit trail
Simple History keeps a "who changed what, when" record on sensitive data, so there's a clear trail behind important changes.
Per-school data isolation
Every record is stamped with the school it belongs to, and every screen is filtered by that stamp. One product, many schools, zero data mixing — a teacher at one school can never see a student, mark, or fee from another.
Login safety features
Forced password change on first sign-in, sessions logged out everywhere when a password changes, a full login history of every attempt, and password reset by a one-time code over SMS or email.
Encrypted secrets
Sensitive keys — like a school's payment credentials — are stored scrambled, not as plain text. On the web the login pass is a hidden cookie that scripts can't read, with cross-site protection.
How access is granted
The admin creates the login
The school admin creates a staff or parent account and hands over a temporary password. The new user is blocked until they set their own.
Permissions are switched on
Starting from zero access, the admin applies a template or toggles individual modules and submodules, choosing View, Edit, or both.
Every action is checked
When a staff member opens a screen or saves, the server checks the matrix first. The app hides menus they can't use, but the real enforcement is on the server, so it can't be bypassed.
Sensitive changes are logged
Money and staff-admin screens are flagged sensitive, and the audit trail records who changed what and when.
Why it matters for trust
A deliberate, hard rule runs through the whole product: our own team can never see or touch a school's fee money — not the fee structures, not the payments, not the payment-gateway credentials. Schools own their fee data entirely. Accounts are created top-down, and no one can quietly promote themselves, which prevents privilege escalation.
A note on scope: these are the access controls and safety features documented today — four login types, role-based permissions, audit trail on sensitive data, per-school isolation, and encrypted secrets. We don't claim SSO or any external compliance certification.
See Admin & Security on your own data.
A 30-minute walkthrough tailored to your institution. Bring your current admissions process; leave with a clear migration plan.