MDH e-school ERP

Role guide and training

What each role can do, how requests move through the platform, illustrated end-to-end journeys, and an optional embedded training video.

System architecture

All roles use the same Next.js app in the browser. It calls a single Express API (JSON over HTTPS). The API validates JWTs, resolves school scope, then reads and writes PostgreSQL and local file storage. Nothing in the database is shared across schools without an explicit schoolId filter.

Request path

Role-based users

Browsers · desktop & mobile

Super AdminSchool AdminTeacherStudentParentAccountantHR

Next.js web application

App Router · React · Tailwind · client auth & school headers

/erp-api/*JWT in headerX-School-Id

Express API

One HTTP service: routes per module (students, fees, exams, HR, …). Every school-scoped call is checked against the signed-in user and active school context.

Middleware chain

  • JWT validation
  • Resolve school / scope
  • Zod validation
  • Prisma data access

PostgreSQL

Single database, schoolId on rows for tenant isolation.

File storage

Uploads (documents, ID assets, exam media) on disk or compatible storage, paths referenced from the API.

Optional services (e.g. Redis cache, email SMTP, payment gateways) connect from the API layer only — not from the browser.

End-to-end flows

Step-by-step visuals for the main journeys in the product. Each diagram is rendered as part of the page (no external diagram engine required).

Sign-in and school context

Most routes require authentication; super-admin flows add an explicit school context step.

Authentication path

Open login

MDH School ERP sign-in

Email & password

Submitted to /auth/login

Valid JWT?
Yes → continueNo → error UI

Dashboard

Shell & nav by primaryRole

After login — school context

Super Admin?
Yes → pick schoolNo → school on token

Schools → Open as context

Sets X-School-Id for this session

School-scoped screens

Fees, students, exams, etc. for that tenant

Other roles

School is already on the JWT and/or header from login — no extra context step.

Admission → enrollment → class

Public enrollment forms feed admin review; approved students become first-class records in the school.

Admission → enrollment → class

1

Public / parent

Submit admission

Open enrollment form for school code

2

System

Queue application

Visible in student registrations

3

School admin

Review & approve

Check documents & eligibility

4

System

Create student

Profile + section assignment

5

Family

Access portals

Student / parent login linked

Fees: structure → assignment → payment

Accountants configure structures; families pay through the portal when gateways are enabled.

Fee lifecycle

Setup

  • Fee structure
  • Assign to class / student

Payment

  • Open Fees (parent or student)
  • Pay online or record offline

Post-payment

  • Receipt & ledger
SUPER_ADMIN

Super admin platform loop

Monitor SaaS health first; switch into tenant scope only when needed.

SCHOOL_ADMIN

School admin operational loop

Run the tenant day: setup, students, operations, HR/finance.

TEACHER

Teacher daily teaching loop

Assignments, attendance, assessments, and online exams share section scope.

ACCOUNTANT

Accountant finance loop

Configure structures, record payments, reconcile receipts and ledger.

HR

HR staff-org loop

Department + job title catalog, then leave and payroll/letters.

STUDENT

Student visibility loop

Timetable, attendance, fees, exams, and homework in personal screens.

PARENT

Parent visibility loop

Choose a child, then view results, timetable, homework, and fees.

Migrating from another ERP

Schools often replace an older product mid-year or between sessions. MDH is multi-tenant: every row is scoped to a schoolId, and admission, registration, and employee numbers are generated per school so you will not collide with other tenants. Use this standard so current operations stay accurate while history stays trustworthy.

Signed-in schools

After login, open Data migration to initiate the checklist and update your school's migration phase.

Actions by role

Navigation in the app is filtered by primaryRole. The list below matches the modules wired in the shell.

SUPER ADMIN

Platform owner

Click to expand actions

SCHOOL ADMIN

Principal / operations

Click to expand actions

TEACHER

Class & subject teacher

Click to expand actions

ACCOUNTANT

Finance office

Click to expand actions

HR

Human resources

Click to expand actions

STUDENT

Learner portal

Click to expand actions

PARENT

Guardian portal

Click to expand actions

Departments & titles (HR)

HR uses a staff-org catalog to group employees by department and designation / job title. This matches the HR “Add employee” form and the fields stored on each employee record.

HR staff-org

Departments + job titles model

Expand for catalog + save rules

Training video

Record your walkthrough (screen capture + voice), upload it to YouTube or another host, then point the app at the public URL below.

Embed your video

Set NEXT_PUBLIC_ERP_TRAINING_VIDEO in frontend/.env.local to a full YouTube watch URL or direct embed URL. The legacy name NEXT_PUBLIC_ERP_TRAINING_VIDEO_HINDI is still read if the new variable is unset. Rebuild or restart next dev after changing env.

Video placeholder

Add NEXT_PUBLIC_ERP_TRAINING_VIDEO (or the legacy NEXT_PUBLIC_ERP_TRAINING_VIDEO_HINDI) to show an embedded video here.

Ready to try the app?

Go to login