Management information system

MIS for ABIS

A role-aware school MIS connecting people, classes, attendance, grades, timetables, and reporting across one academic data model.

The problem

The same academic records must serve administrators, teachers, students, and parents without exposing every workflow to every role.

Built with

Client
Al-Beruniy International School
Year
2026
Role
Full-stack architecture and implementation
Status
Private staging, walkthrough on request

Screens

  • ABIS MIS presented across desktop and mobile dashboards
  • The weekly register grid showing each student's attendance mark and grade for every lesson
  • The weekly timetable grid with subjects and teachers in each period
  • The weekly schedule builder for a class with a subject, teacher and room in every period slot
  • The assignments table with teacher, due date and submitted-versus-graded counts
  • The enrollment pipeline with stage counters above a case list ordered by next action
  • The payment registry listing students with their branch, group and payment state
  • The reports and analytics view with school totals, an average grade and an attendance rate

Desktop and mobile

The role-aware school MIS on desktop and mobile: one academic data model behind every role's view of it.

Weekly register

A week of one class, subject by subject: the attendance mark and the grade recorded together.

Timetable

The recurring weekly schedule for a class, by period and by teacher.

Schedule builder

Building the week for a class: every period given a subject, a teacher and a room, drafted before it is saved.

Assignments

Every assignment in the school with its teacher, its due date, and how much of it is graded.

Enrollment pipeline

Prospective families moved between admission, reception and account activation, prioritised by next required action.

Payment registry

Paid and unpaid periods for every student, by academic year, branch and period.

Aggregate reporting

Roll counts, assignment volume, average grade and attendance rate across the school.

1 / 8

System

People and roles School structure Learning activity Attendance and grades Role dashboards Reports and analytics RBAC One school model, four role perspectives People and roles School structure Learning activity Attendance and grades Role dashboards Reports and analytics RBAC One school model, four role perspectives

Features

Role-scoped command palette

Command+K searches only what your role is allowed to see.

Active child selector for parents

One parent, several children. Switch, and every page follows.

Grades gated by attendance status

A grade needs Present or Late. Changing that clears the grade.

Public password assistance intake

A sign-in help page, separate from the authenticated ticket queue.

Timetable subgroups covering all students

Split a class slot into subgroups. Every student lands in exactly one.

Teacher access scoped to subjects

Teachers see the subjects they teach. Homeroom teachers see everything.

Decisions and tradeoffs

Problems we hit

Clearing grades when attendance changes

Problem

Grades can only exist with matching present-or-late attendance, so changing a teacher's attendance record to absent invalidates dependent grades.

Our solution

Count, confirm, clear in one transaction

The server calculates the affected count, waits for teacher confirmation, and clears the grades in the same transaction that updates attendance. Legacy write routes enforce the same invariant.

Background polling resetting the idle timeout

Problem

The idle timeout is defined as real user inactivity, not token age, which background polling from the notification centre does not represent.

Our solution

Separate activity from background traffic

Background requests from the notification centre and other polling features are excluded from resetting the inactivity clock. This required separating user-activity tracking from background request handling at the session layer.

Decisions we made

Shared academic entities, not feature pages

Decision

The primary decision was to build around shared academic entities instead of feature-by-feature pages.

Why we made it

That makes reporting possible because attendance, grades, assignments, and workload can be evaluated against the same people, subjects, and groups.

Desktop density, responsive learner access

Decision

The second decision was to keep high-density administration and reporting on desktop while maintaining responsive learner access.

Why we made it

Students and parents may check schedules or assignments from smaller screens; administrators still need broad, scan-friendly working surfaces.

Support built into the product

Decision

The system also includes support and language selection as part of the product rather than launch-only assistance.

Why we made it

A multi-role school system needs a clear way to recover when users cannot complete a workflow.

Next

Contact

Let's talk.

For professional opportunities, collaborations, or selected freelance work.

Open to conversations Frankfurt, Germany Europe/Berlin