School MasterSeparate access paths
Parent, school-owner/admin and staff login paths are kept separate. Parent accounts cannot inherit staff ERP permissions, and staff password login does not accept parent accounts.
Layered controls for school operations.
Security in School Master is built around tenant separation, role permissions, controlled sessions, auditability, safe imports/restores and additional verification for sensitive workflows.
Last updated: 27 August 2026Role and scope controls
Modules use explicit permissions such as view, add, edit, delete, approve, finalize, export and restore. Class/division scope can additionally restrict users to authorized students and workflows.
Tenant isolation
Customer-school records use SchoolId-scoped query filters and write assignment. Automated PostgreSQL integration QA uses separate synthetic schools to verify that one school cannot read another school's tenant rows.
Session protection
Tracked user sessions can be revoked. The application uses inactivity handling and heartbeat checks for signed-in non-demo users, and sensitive routes can require recent security verification.
Hybrid device security
Offline PCs require explicit one-time enrollment. Device tokens are protected locally, cloud-authoritative users/permissions/edition cannot be changed from Local mode, and sync conflicts are surfaced instead of silently overwriting competing edits.
Audit trail
Security-sensitive and operational actions are written to audit workflows where implemented, supporting accountability for changes such as attendance corrections, imports, payments and administrative actions.
Safe mapped imports
Flexible Excel column mapping changes header compatibility only; it still flows through the same required-field, duplicate-key, class-authority and transaction checks as the official School Master import.
Backup and restore protection
Cloud restore validates school identity, references and duplicate keys, preserves live authentication/permissions/subscription data, creates a pre-restore checkpoint in the UI workflow and applies operational replacement transactionally with rollback on failure.
Payment verification
Razorpay/payment workflows are designed to verify provider signatures, currency, exact amount and successful provider state before entitlement or receipt actions. Duplicate provider/payment references are guarded for idempotency.
WhatsApp webhook security
Meta delivery callbacks remain dependent on correct provider configuration. Webhook verification token and App Secret support secure callback validation; real provider activation is kept separate from code readiness.