Telente School Management
A school operations system covering admissions, attendance, timetables, results, fees and staff — with role-based access separating what students, teachers and administrators can reach.
- 10
- Route modules
- 9
- Controllers
- 4
- User audiences
- 6
- Operational domains
- Role
- Author
- Year
- 2026
- Status
- Private
- Type
- School management system
01Overview
Telente School Management handles the operational side of running a school: student admission and registration, attendance, class management, timetables, results and reporting, fee and payment tracking, staff records, announcements and system administration.
The users are not one audience. Students, teachers, administrators and finance staff share the same data and need very different slices of it, which makes role-based access the organising constraint rather than a feature.
It also carries the unglamorous parts schools actually depend on: email notifications, permissions, settings and system backups.
02The problem
School software fails on the calendar. Terms, sessions and classes all move, and a schema that treats a student's class as a column rather than as an enrolment in a term cannot answer what a student took two years ago.
Results are the second trap. A grade is not a single value — it is components, weights and a computed total, and a system that stores only the total cannot explain or correct it.
The third is access. Attendance, results and fees are visible to overlapping but different groups, and getting that wrong means a parent seeing another child's record.
03Architecture
- 01
Student lifecycle
Admission, registration, attendance and progress tracking as connected stages rather than as separate screens over the same table.
- 02
Academic operations
Class management, timetabling, results and reporting — the recurring machinery of a term.
- 03
Finance
Payment tracking, billing and financial reporting kept beside the student record it belongs to.
- 04
Roles and permissions
Staff and administrator management with role-based access, so what a teacher can reach and what a bursar can reach are defined once and enforced centrally.
- 05
Operations
Email notifications, announcements, system settings and backups — the features that decide whether a school can actually run on the system.
04Key decisions
Backups as a product feature
A school's records are not recoverable from anywhere else. Making backup a function of the system rather than an operational assumption is the difference between an incident and a catastrophe.
Role-based access as the foundation
With four audiences over one dataset, retrofitting authorisation means auditing every query. Defining roles first makes every later feature inherit the boundary.
Notifications in the system
Announcements and email notifications built in, because the alternative is a parallel WhatsApp group that becomes the real source of truth.
05Stack
- Node.js
- Express
- MySQL
- JavaScript
- RBAC