The shared dashboard problem
Picture a school ERP demo where the vendor opens "the dashboard" and scrolls through twenty menu items. Admissions. Fees. Exams. Transport. HR. Library. Reports. Settings. The principal nods. The accountant wonders where the fee ledger hid. The class teacher asks why exam marks sit next to payroll.
That single-screen approach fails for two predictable reasons. Security: if everyone logs into the same interface, either sensitive modules are exposed to people who should not see them, or permissions are so locked down that half the menu errors when clicked. Usability: staff ignore software that makes them hunt for the three tasks they repeat every day.
Indian schools run on specialised roles organisation trustees, campus directors, academic coordinators, finance officers, HR, teachers, parents, students. Each role has a different rhythm. KIDUART responds with role panels: dedicated views over one database, filtered by permission, not separate products stitched together.
One database, ten panels
Every panel reads the same student, fee, attendance, and staff records. A mark entered by a teacher appears in the academic coordinator's view and the parent's portal. A fee payment recorded by finance updates the principal's collection summary. The difference is what each role is allowed to open and what the sidebar shows on login.
KIDUART ships ten role panels today:
- System admin
- Organisation
- Director and leadership
- School admin
- Academic coordinator
- Teacher
- Finance and accounts
- HR and staff
- Parent
- Student
Below is how each panel is meant to be used not as a feature checklist, but as a narrative of who sits where and why a shared dashboard would get in their way.
System admin panel
The system admin panel is for the team that keeps the platform healthy across tenants infrastructure, global configuration, and support escalations that should not be mixed with day-to-day school work. School staff rarely live here. It exists so operational boundaries stay clear: a principal configures their school; platform administration stays separate.
School buyers evaluating ERP software should ask whether "admin" means school admin or vendor admin. Conflating the two is how schools accidentally grant support vendors permanent access to student data.
Organisation panel
Trusts and school groups running multiple campuses need a layer above a single campus. The organisation panel is that layer: session structure, group-wide policies, cross-campus reporting, and delegation down to individual schools without merging their data.
Organisation users see rollups collections, enrolment, attendance trends while each campus remains in its own tenant. A director at one campus cannot browse another campus's student records just because they share a brand name. Isolation is structural, not a filter someone might forget.
For groups comparing ERP options, the organisation panel is the difference between "we run five spreadsheets" and "we run five schools with one governance view."
Director and leadership panel
Directors and principals need signal, not every data-entry screen. The leadership panel emphasises summaries: collections against targets, absenteeism patterns, staffing gaps, and academic milestones the numbers that shape a Monday morning meeting.
Leadership users should not wade through class timetables to find last week's fee total. They also should not have blanket access to edit marks or fee entries unless policy explicitly requires it. The panel is tuned for read-and-decide work, with permissions that respect separation of duties.
School admin panel
The school admin panel is the operational hub for a campus: classes, sections, subjects, student records, staff accounts, session calendar, and the configuration that other panels depend on. Most rollout guides start here organisation and session first, then classes, then students, then the fee book, then roles.
School admins delegate downward. They create teacher accounts, assign classes, and enable modules the school purchased. They do not need the finance team's full ledger if policy says accounts owns collections and in KIDUART, they will not see it unless permission allows.
Academic coordinator panel
Academic coordinators live between leadership and teachers: exam schedules, grade policies, promotion rules, curriculum mapping, and the oversight that keeps reporting cycles on time. Their panel centres on academic structure and outcomes rather than fee heads or payroll.
When exam marks are due, coordinators need visibility across sections without opening every teacher's login. They need promotion workflows that respect the single student profile not a export from one module pasted into another.
Teacher panel
Teachers adopt software that saves taps. The teacher panel focuses on attendance, class notices, grade entry, diary notes, and the small set of tasks repeated every period. Extra screens mean extra resistance, no matter what the sales deck promises.
A class teacher should never land on the fee ledger by default. In role-based panels, they simply do not see it. Menus reflect real permissions not a wall of greyed-out icons that tempt curiosity.
Training for teachers is short when the screen matches the job. Rollout plans that train "the whole ERP in one day" fail; rollouts that train teachers on the teacher panel succeed more often.
Finance and accounts panel
Finance staff own the fee book: structures, allocations, counter collection, online reconciliation, receipts, refunds, expenses, and dues lists that drive reminders. Their panel is built for ledger work not for editing exam schedules.
Online payments through Razorpay or Stripe post back through verified webhooks. Counter receipts use the same numbering logic. When a parent pays by UPI at midnight, the record should exist before the office opens not after someone matches a bank SMS.
Accountants still export to familiar tools for statutory work where needed. The panel removes duplicate entry inside the school; it does not pretend to replace every external accounting package.
HR and staff panel
HR manages hiring records, staff profiles, leave, attendance for employees, and the permissions that gate every other panel. HR data is sensitive in its own way salaries, documents, disciplinary notes and belongs separate from student modules.
When a teacher resigns mid-term, deactivating their account should end access, not merely hide a menu. Session revocation and role removal are part of secure offboarding, not an afterthought.
Parent panel
Parents are not administrators. The parent panel shows their children's attendance, fees, notices, grades when published, diary entries, and transport details where enabled narrow by design.
Guardians pay dues from the portal when online collection is live. They receive absence alerts when attendance is marked. They do not browse other students' records or school-wide finance. Privacy follows from role, not from hope.
Student panel
Where schools enable it, students see timetables, assignments, published results, and notices relevant to their class. The student panel is lighter than staff views and respects that minors use the system too.
Why panels beat "custom dashboards"
Some products offer configurable dashboards drag a widget here, hide a tile there. That helps power users but does not solve role confusion for a fifty-person staff with mixed digital confidence.
Role panels encode school operations into navigation. A new finance hire learns the finance panel, not the entire product. A parent opens the parent app and sees child information, not admin settings buried behind a logo.
Permissions and panels stay aligned. An organisation can restrict what a school admin may grant without letting them expand their own access delegation flows downward by design.
Training and rollout implications
KIDUART rollout follows module order: organisation and session, classes, students, fee book, roles. Training mirrors panels: front office learns school admin tasks; teachers learn attendance and grades; accounts learns the fee book; leadership learns dashboards.
That approach reduces the "everything at once" failure mode. It also maps cleanly to vendor evaluation: ask each stakeholder to spend fifteen minutes in their panel during a demo, not watching someone else's workflow.
Security is not a bolt-on layer
Role panels only work if permissions enforce them. KIDUART stores passwords hashed with bcrypt, supports authenticator-app MFA for staff, separates tenants per school, and logs sensitive actions. A panel you cannot see should also be a module you cannot API around without scoped keys.
We do not claim certifications we have not completed. We do describe controls that exist today for IT reviewers comparing school software.
When one dashboard still makes sense
Very small institutions with three staff wearing every hat sometimes ask for a single simplified view. Even then, parents and students should remain on narrow portals. The principle holds: match the screen to the job, keep one database underneath.
Evaluating vendors: panel walkthrough script
Ask each stakeholder to spend fifteen minutes in their panel during a demo:
- Principal: leadership summaries and cross-module reports
- Accountant: fee book end-to-end including online reconciliation
- Teacher: attendance and grade entry only
- Parent: child-specific portal on a test account
If the vendor navigates everything from one super-admin login, you are not seeing role panels you are seeing a performance.
If your current ERP feels "powerful" but empty in daily use, the issue may not be missing features. It may be that everyone is lost in the same dashboard. Role panels exist to fix exactly that.
