Where is access control enforced?

In the database, as row-level security and lock triggers, rather than in the interface. That matters because an interface check only protects the interface, while a database rule applies to every client that asks.

Can one institute see another institute's data?

No. Multi-tenant isolation is part of the same database layer and applies to every education table, including all eight fee tables with their real foreign keys.

Is there a teacher login scoped to their own batches?

No. Staff exists as an entity type covering teachers, faculty and admin, but it is not a separate sign-in scoped to a batch. If that is a requirement for you, raise it with us rather than assuming it is there.

Are the mobile apps real, or a mobile website?

Both iOS and Android are live as apps, and there is a progressive web app as well.

Does every user see every module?

No, and that is intentional. What a user sees depends on plan, role and the settings for your institute, which is how a front-desk clerk and an owner can work in the same workspace.

Platform and security

Access control the interface cannot talk its way around.

Student data is the kind you only get to lose once. Access control here is enforced where the data lives, not in the screen that displays it — which is the difference between a rule and a suggestion.

Book a demo See pricing

What this covers

1Enforced where the data isRow-level security per role
2One institute cannot see anotherTenant isolation on every education table
3Audit trailsAudit trails across the platform
4Mobile, for the people not at a deskiOS app live

In short

What does platform & security do in RaivatEdu?

Role-based access and multi-tenant isolation are enforced in the database through row-level security and lock triggers, not in the interface, so a request that should not return a row does not return it regardless of which client asks. Audit trails record what happened, and native iOS and Android apps are live alongside the web app.

level access control: Database
data isolation: Per tenant
both live: iOS + Android

What platform & security does today.

Every line here is a feature that exists in the product right now. Anything still being built is listed further down, on the same page.

Enforced where the data is

Role-based access runs as row-level security and lock triggers in the database. An interface check can be bypassed by anything that is not the interface. A database rule cannot, which is why the fee guarantees hold as well as they do.

Row-level security per role
Lock triggers on records that must not change
Applies to every client, not just the web app

One institute cannot see another

Multi-tenant isolation is part of the same layer. Every education table carries the tenant boundary, including all eight fee tables and their foreign keys.

Tenant isolation on every education table
Real foreign keys, not conventions
Applies to the fee schema too

Audit trails

What happened, and when. The fee module leans on this hardest: an immutable receipt is only half the answer if nobody can see what was attempted.

Audit trails across the platform
Revision history on certificate text
Adjustments recorded rather than overwritten

Mobile, for the people not at a desk

iOS and Android apps are both live, plus the progressive web app. A counsellor at an education fair and a front-desk clerk taking a fee are not the same user on the same device.

iOS app live
Android app live
Progressive web app

Where this stops

What platform & security does not do.

We would rather you read this before you buy than discover it in week two. If something here is a requirement for you, tell us and we’ll be straight about the timeline.

Ask us about a gap

Roles cover the platform's own set. There is no teacher role scoped to a batch: staff exists as an entity type for teachers, faculty and admin, not as a separate scoped sign-in.
Features are available subject to plan, role and per-institute settings, so not every user sees every module.

FAQ

Platform & Security, answered plainly.

In the database, as row-level security and lock triggers, rather than in the interface. That matters because an interface check only protects the interface, while a database rule applies to every client that asks.
No. Multi-tenant isolation is part of the same database layer and applies to every education table, including all eight fee tables with their real foreign keys.
No. Staff exists as an entity type covering teachers, faculty and admin, but it is not a separate sign-in scoped to a batch. If that is a requirement for you, raise it with us rather than assuming it is there.
Both iOS and Android are live as apps, and there is a progressive web app as well.
No, and that is intentional. What a user sees depends on plan, role and the settings for your institute, which is how a front-desk clerk and an owner can work in the same workspace.

See the whole feature inventory

Your next student is already looking for you.

Give your admissions team one place to capture, connect and convert every opportunity.

Book a demo Talk to our team

Rather talk it through? Request a callback or talk to sales.

30-minute walkthrough
Your workflow, not a script
No card required