The receptionist shouldn't see payroll. The accountant shouldn't see medical histories. Most school ERPs let everyone see everything.

The permission grid — module-by-module, six actions per cell

Every SchoolDeck module is represented in the role's permission grid. For each module the role can be granted up to six actions:

• View: Can open and read records in this module.
• Create: Can add new records.
• Edit: Can modify existing records.
• Delete: Can soft-delete records (hard delete is reserved to Super Admin and always logged).
• Approve: Can approve workflows that other roles initiated — e.g. fee waiver requests, expense vouchers, mark corrections.
• Export: Can download data as CSV / PDF / Excel. Export is the action with the highest data-exfiltration risk — schools often grant View and Edit but withhold Export for everyone below the Vice-Principal level.

A Junior Accountant in a typical Indian school is granted: Fees module — View, Create, Edit, Export; Expense module — View, Create (but not Approve); all other modules — nothing. A Counsellor: Students module — View limited to own counselling caseload; Counselling Notes module — View, Create, Edit; all other modules — nothing.

The Trust HR or Super Admin sees the role grid as a matrix and ticks boxes. Three minutes to define a new role from scratch.

Row-level scope and field-level scope — both matter

Two distinct scope dimensions decide what a role can actually see in the data.

Row-level scope controls which student records the role can access at all. A Class 9-A teacher with row-scope = own class sees the 40 students in 9-A — the other 1,960 students in the school are not searchable, not viewable, not even auto-completing in a search box. They are mathematically invisible to that role's queries.

Row-scope options:

• Own class: Only students in the role-holder's assigned section. Default for Class Teacher.
• Own grade: All sections of the role-holder's assigned grade. Default for Academic Coordinator.
• Own department: All students taking subjects in a department. Default for HOD.
• Own branch: All students in the role-holder's branch — combined with the API-level partition from /features/multi-branch/.
• School-wide: Everyone. Default for Principal.
• Custom filter: Arbitrary criteria — e.g. "students enrolled in the boarding house" for the Hostel Warden role.

Field-level scope controls which fields within a record are visible to the role. A Transport Coordinator legitimately needs the student's name, class, home address and bus route — but their role's field scope hides the medical-allergy field, Aadhaar number, parent income certificate, fee outstanding, academic marks. The same student record renders differently to different roles. This is the SchoolDeck implementation of DPDP Act 2023's purpose-limitation principle in software.

DPDP, POCSO, JJ Act — three frameworks, three role-catalogue alignments

India's three primary child-data and child-safety frameworks each impose specific requirements on how a school's staff can access student records. SchoolDeck's role catalogue addresses each.

DPDP Act 2023 (assented August 11, 2023; Phase III full-compliance deadline May 13, 2027) classifies schools as Data Fiduciaries for the personal data of minors. The Act requires (a) verifiable parental consent at data collection, (b) purpose limitation — data collected for one purpose cannot be reused for another, (c) reasonable security safeguards. RBAC is the technical implementation of purpose limitation: a transport coordinator's access serves the transport purpose; their access is limited to transport-relevant data. A medical compliance audit can verify the role-permission matrix at any time. The audit trail in /features/audit-logs/ is the documentary proof.

POCSO Act 2012 requires schools to maintain background-check clearance for all staff with direct student contact. SchoolDeck's role catalogue allows student-contact roles (Class Teacher, Subject Teacher, Counsellor, Sport Coach, House Master) to be gated behind a POCSO clearance flag on the staff profile. If the clearance has not been recorded — or has expired — the role cannot be assigned to that staff member. The Trust HR sees a clear "POCSO clearance required" message when attempting the assignment.

JJ Act 2015 Sec 41-42 protects child welfare records. A counsellor's notes on a student's emotional wellbeing, family circumstances or any disclosure that may affect child welfare are not general school records — they are restricted to the Counsellor role. The Principal does not see counselling notes by default; the Class Teacher does not see them; a substitute Counsellor temporarily covering can see only the notes they themselves authored unless explicitly elevated by the Designated Child Welfare Officer.

One-click staff deactivation — closing the resignation window

The highest-risk moment in any school's data security year is the week after a senior staff member's resignation — particularly when the resignation is not amicable. In schools with shared admin passwords, that week ends with the credential finally being changed and all remaining staff informed of the new password. In between, data exfiltration is unrestrained.

SchoolDeck's RBAC eliminates that window. When the Super Admin or Trust HR toggles a staff member's status to Deactivated, the following happens within seconds:

• Web portal authentication is rejected — even if the staff member is currently logged in on a browser, the next page load fails.
• Mobile app sessions terminate — the SchoolDeck app on their phone logs them out and clears cached data.
• Every active session token across every device is destroyed — they cannot continue from a saved login.
• The unique login credentials are permanently disabled.
• Their entire historical audit trail in /features/audit-logs/ is preserved intact — every action they ever took, every record they viewed, remains in the immutable trail for institutional records.

For staff on planned exit (notice period), the deactivation can be scheduled to a specific date and time. For acrimonious resignations, the toggle is immediate.

The external auditor role — time-limited, module-scoped, view-only

Every year, the Trust's CA needs access to fee ledgers, expense vouchers, payroll summaries and P&L reports for the annual audit. The traditional approach — sharing full admin credentials with the CA — is a data governance failure. The CA may be trustworthy; the credentials may not stay in their personal control; and there is no record of what they actually viewed.

SchoolDeck ships a pre-built "External Auditor" role configured as: View-only across Finance + Fees + Expense modules; no access to student academic records, medical, parent contact, payroll details beyond salary aggregates; time-limited login (the role automatically deactivates on a configured end-date — typically 30 days from creation, extendable); IP whitelisting optional but recommended (the CA's office IP, or the school campus IP if the audit happens on-site).

Every record the auditor views is logged in /features/audit-logs/. After the audit window, the role auto-deactivates and the audit log shows exactly what was reviewed. If a future regulatory inquiry asks "who saw which records during the FY25 audit?" — the Trust has a verifiable answer.

The parent role — cryptographically bound to the child UID

Parents are users of the school ERP too — through the SchoolDeck parent app. Their access raises a specific question: can a parent see another family's student data, accidentally or deliberately?

The architectural answer: no. The parent role is not a standard "user" with broad access — it is a role bound at session-token level to the specific Student Unique ID of their child. Every API call the parent app makes carries this binding. Any query for any other student's data fails authentication. This is enforced at the API layer, not the UI.

For parents with multiple children — including children in different campuses of the same Trust — the Family ID system aggregates the bound Student UIDs into a single login. The parent sees all their children in one app session. They do not see any other family's children. They cannot query another family's children even by altering URLs or attempting API calls directly. The binding is mathematical.

RBAC ≠ Audit Logs ≠ Multi-Branch ≠ Maker-Checker

The SchoolDeck security architecture is split across four feature pages, each owning a distinct layer. Knowing the boundaries helps schools evaluate them correctly.

• This page · /features/role-based-access/ — Owns the role catalogue and permission definition. What named roles exist, what each role can View / Create / Edit / Delete / Approve / Export per module, row-scope and field-scope. The rules.
• /features/audit-logs/ — Owns the immutable forensic trail. A record of who actually did what, when, from where. Cannot be deleted by anyone. DPDP Act 2023 Phase III ready by May 13, 2027. The watching.
• /features/multi-branch/ — Owns cross-campus branch fencing at the API level. How a Branch A Principal's session is scoped to Branch A's data partition so they cannot query Branch B data even by altering URLs. The cross-campus boundary.
• /features/finance-management/ — Owns Maker-Checker dual control on financial transactions. Payment vouchers require separate Maker (Junior Accountant) creation and Checker (Finance Head) approval. The dual-approval workflow.

Each layer is needed; none replaces the others. RBAC defines who can do what; the audit log records who actually did what; multi-branch fences across campuses; Maker-Checker imposes dual approval on financial actions. SchoolDeck's complete access architecture sits on all four.

Two-role legacy ERP vs SchoolDeck RBAC

What changes for a 1,800-student Indian school's role architecture.