Personas & Permissions

Five users. One database. Carefully different views. The full permission matrix and how each persona logs in.

The school SaaS has five kinds of users. Each sees a different subset of the same database, decided by their role and (for most) their assigned branch. This page is the definitive permission matrix and how to bring each persona to life.

The Five Personas

Persona	Who they are	What they care about
Super Admin	The school's owner/principal across all branches	Everything across all branches: enrolment numbers, revenue, attendance trends.
Branch Admin	The principal or office manager of one campus	Their branch's students, teachers, fees, day-to-day operations.
Teacher	A teacher assigned to one or more sections	Their assigned sections — attendance, marks, parent contact.
Parent	The parent of one or more enrolled children	Their child's attendance, marks, fees, circulars.
Student (optional v1.5)	Older students (grade 6+) reading their own data	Their own marks, attendance, schedule.

Every persona logs in with the same email/password screen. The system reads profiles.role after login and routes accordingly.

The Full Permission Matrix

                                 │ Super │ Branch │ Teacher │ Parent │ Student
                                 │ Admin │ Admin  │         │        │
─────────────────────────────────┼───────┼────────┼─────────┼────────┼─────────
Manage branches                  │   ✓   │        │         │        │
Manage admins                    │   ✓   │   ✓¹   │         │        │
Manage teachers                  │   ✓   │   ✓¹   │         │        │
Manage students                  │   ✓   │   ✓¹   │         │        │
Manage parents                   │   ✓   │   ✓¹   │         │        │
Manage class sections            │   ✓   │   ✓¹   │         │        │
View students (read-only)        │   ✓   │   ✓¹   │   ✓²    │   ✓³   │
View own child                   │       │        │         │   ✓    │
View own data                    │       │        │         │        │    ✓
Mark attendance                  │   ✓   │   ✓¹   │   ✓²    │        │
View attendance history          │   ✓   │   ✓¹   │   ✓²    │   ✓³   │    ✓
Create exams                     │   ✓   │   ✓¹   │   ✓²    │        │
Enter exam marks                 │   ✓   │   ✓¹   │   ✓²    │        │
View own marks                   │       │        │         │   ✓³   │    ✓
Set fee plans                    │   ✓   │   ✓¹   │         │        │
Trigger / view payments          │   ✓   │   ✓¹   │         │   ✓³   │
Pay fees                         │       │        │         │   ✓³   │
Compose circulars                │   ✓   │   ✓¹   │         │        │
Receive circulars                │   ✓   │   ✓    │   ✓     │   ✓    │    ✓
Cross-branch reports             │   ✓   │        │         │        │

Footnotes:

¹ Limited to their assigned branch only.
² Limited to their assigned section(s) only.
³ Limited to their own children's data only.

This matrix is what your RLS policies enforce. Never enforce a permission in only the UI — anyone with the API key can bypass UI checks.

How Each Persona Logs In

Each persona uses the same /login page but is routed to a different home after login.

Persona	Routed to	What they see first
Super Admin	`/admin`	Dashboard with all branches, total enrolment, payment summary
Branch Admin	`/admin`	Same UI as super admin, but data filtered to their branch (RLS enforces this)
Teacher	`/teacher`	List of their sections; click to mark attendance / enter marks
Parent	`/parent`	List of their children; click to see attendance / marks / fees
Student	`/student`	Their own dashboard — marks, attendance, schedule

You don't need to build separate apps. One Next.js app, route guards based on role.

In Project 2 the contact form didn't need auth. In Project 3 every page does. The auth flow:

User visits any URL.
Middleware checks for a Supabase session cookie.
If no session → redirect to /login.
After successful login, look up profiles.role.
Redirect based on role:
- super_admin or branch_admin → /admin
- teacher → /teacher
- parent → /parent
- student → /student

Code sketch (in src/middleware.ts):

import { createServerClient } from '@supabase/ssr'
import { NextResponse, type NextRequest } from 'next/server'
 
const PUBLIC = ['/login', '/forgot-password', '/auth/callback']
 
export async function middleware(req: NextRequest) {
  const { pathname } = req.nextUrl
  if (PUBLIC.some(p => pathname.startsWith(p))) return NextResponse.next()
 
  const res = NextResponse.next()
  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    { cookies: { getAll: () => req.cookies.getAll(), setAll: () => {} } }
  )
  const { data: { user } } = await supabase.auth.getUser()
  if (!user) return NextResponse.redirect(new URL('/login', req.url))
 
  return res
}
 
export const config = { matcher: ['/((?!_next/static|_next/image|favicon|public).*)'] }

Then per-route components also check profiles.role server-side and either render or 404. Defense in depth.

Creating Test Users (Seed Script)

Before you start building features, seed a few test users so you can develop against realistic data.

In the Supabase SQL editor (use the service role with caution — only for seeding):

-- Note: use Supabase Auth dashboard or the admin API to create the actual auth.users entries.
-- The profile rows below assume those users exist.
 
insert into public.branches (id, name, city) values
  ('11111111-1111-1111-1111-111111111111', 'Andheri', 'Mumbai'),
  ('22222222-2222-2222-2222-222222222222', 'Powai', 'Mumbai'),
  ('33333333-3333-3333-3333-333333333333', 'Thane', 'Mumbai');
 
insert into public.profiles (id, email, full_name, role, branch_id) values
  ('<auth.uid of super>', 'super@aurora.test', 'Super Admin', 'super_admin', null),
  ('<auth.uid of branch admin>', 'admin.andheri@aurora.test', 'Andheri Admin', 'branch_admin', '11111111-1111-1111-1111-111111111111'),
  ('<auth.uid of teacher>', 'teacher.1@aurora.test', 'Class 5A Teacher', 'teacher', '11111111-1111-1111-1111-111111111111'),
  ('<auth.uid of parent>', 'parent.1@aurora.test', 'Arjun Sharma', 'parent', '11111111-1111-1111-1111-111111111111');

Test passwords for development only: use Aurora-Test-2026 or similar. Never reuse on production. Save to VaultMate under category "Test Account."

Once seeded, you can log in as each persona separately to verify the right page renders and RLS isolates the data correctly.

The "Surprise" Permission Cases

Real schools have edge cases that don't fit a clean matrix. Decide upfront how you'll handle them:

Edge case	Recommendation
Parent has children in 2 different branches	Two `parent.children` relationships — one row per child. UI shows a branch dropdown if >1 child.
Teacher transfers branches mid-year	Change `profiles.branch_id`. Past attendance records keep their original `branch_id` — they're already scoped to a section.
A child changes from one section to another	Add `student_section_history` table for the audit trail. The `students.section_id` is "current section."
Two siblings share one parent	One `parents` row, two `students` rows both with same `parent_id`.
A super admin temporarily acts on behalf of a branch admin	Don't fake it. Super admins inherently see everything; they don't need to "switch."

These decisions matter because they shape your foreign keys.

What's Next

Now you have:

The 12-table schema (from the previous page).
The full permission matrix.
Test users seeded.
Per-persona routing decided.

Time to build the first module. Students is the right first module — every other module references students.

Next: Module · Students

The Five Personas

Persona	Who they are	What they care about
Super Admin	The school's owner/principal across all branches	Everything across all branches: enrolment numbers, revenue, attendance trends.
Branch Admin	The principal or office manager of one campus	Their branch's students, teachers, fees, day-to-day operations.
Teacher	A teacher assigned to one or more sections	Their assigned sections — attendance, marks, parent contact.
Parent	The parent of one or more enrolled children	Their child's attendance, marks, fees, circulars.
Student (optional v1.5)	Older students (grade 6+) reading their own data	Their own marks, attendance, schedule.

Every persona logs in with the same email/password screen. The system reads profiles.role after login and routes accordingly.

The Full Permission Matrix

                                 │ Super │ Branch │ Teacher │ Parent │ Student
                                 │ Admin │ Admin  │         │        │
─────────────────────────────────┼───────┼────────┼─────────┼────────┼─────────
Manage branches                  │   ✓   │        │         │        │
Manage admins                    │   ✓   │   ✓¹   │         │        │
Manage teachers                  │   ✓   │   ✓¹   │         │        │
Manage students                  │   ✓   │   ✓¹   │         │        │
Manage parents                   │   ✓   │   ✓¹   │         │        │
Manage class sections            │   ✓   │   ✓¹   │         │        │
View students (read-only)        │   ✓   │   ✓¹   │   ✓²    │   ✓³   │
View own child                   │       │        │         │   ✓    │
View own data                    │       │        │         │        │    ✓
Mark attendance                  │   ✓   │   ✓¹   │   ✓²    │        │
View attendance history          │   ✓   │   ✓¹   │   ✓²    │   ✓³   │    ✓
Create exams                     │   ✓   │   ✓¹   │   ✓²    │        │
Enter exam marks                 │   ✓   │   ✓¹   │   ✓²    │        │
View own marks                   │       │        │         │   ✓³   │    ✓
Set fee plans                    │   ✓   │   ✓¹   │         │        │
Trigger / view payments          │   ✓   │   ✓¹   │         │   ✓³   │
Pay fees                         │       │        │         │   ✓³   │
Compose circulars                │   ✓   │   ✓¹   │         │        │
Receive circulars                │   ✓   │   ✓    │   ✓     │   ✓    │    ✓
Cross-branch reports             │   ✓   │        │         │        │

Footnotes:

¹ Limited to their assigned branch only.
² Limited to their assigned section(s) only.
³ Limited to their own children's data only.

This matrix is what your RLS policies enforce. Never enforce a permission in only the UI — anyone with the API key can bypass UI checks.

How Each Persona Logs In

Each persona uses the same /login page but is routed to a different home after login.

Persona	Routed to	What they see first
Super Admin	`/admin`	Dashboard with all branches, total enrolment, payment summary
Branch Admin	`/admin`	Same UI as super admin, but data filtered to their branch (RLS enforces this)
Teacher	`/teacher`	List of their sections; click to mark attendance / enter marks
Parent	`/parent`	List of their children; click to see attendance / marks / fees
Student	`/student`	Their own dashboard — marks, attendance, schedule

You don't need to build separate apps. One Next.js app, route guards based on role.

In Project 2 the contact form didn't need auth. In Project 3 every page does. The auth flow:

User visits any URL.
Middleware checks for a Supabase session cookie.
If no session → redirect to /login.
After successful login, look up profiles.role.
Redirect based on role:
- super_admin or branch_admin → /admin
- teacher → /teacher
- parent → /parent
- student → /student

Code sketch (in src/middleware.ts):

import { createServerClient } from '@supabase/ssr'
import { NextResponse, type NextRequest } from 'next/server'
 
const PUBLIC = ['/login', '/forgot-password', '/auth/callback']
 
export async function middleware(req: NextRequest) {
  const { pathname } = req.nextUrl
  if (PUBLIC.some(p => pathname.startsWith(p))) return NextResponse.next()
 
  const res = NextResponse.next()
  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    { cookies: { getAll: () => req.cookies.getAll(), setAll: () => {} } }
  )
  const { data: { user } } = await supabase.auth.getUser()
  if (!user) return NextResponse.redirect(new URL('/login', req.url))
 
  return res
}
 
export const config = { matcher: ['/((?!_next/static|_next/image|favicon|public).*)'] }

Then per-route components also check profiles.role server-side and either render or 404. Defense in depth.

Creating Test Users (Seed Script)

Before you start building features, seed a few test users so you can develop against realistic data.

In the Supabase SQL editor (use the service role with caution — only for seeding):

-- Note: use Supabase Auth dashboard or the admin API to create the actual auth.users entries.
-- The profile rows below assume those users exist.
 
insert into public.branches (id, name, city) values
  ('11111111-1111-1111-1111-111111111111', 'Andheri', 'Mumbai'),
  ('22222222-2222-2222-2222-222222222222', 'Powai', 'Mumbai'),
  ('33333333-3333-3333-3333-333333333333', 'Thane', 'Mumbai');
 
insert into public.profiles (id, email, full_name, role, branch_id) values
  ('<auth.uid of super>', 'super@aurora.test', 'Super Admin', 'super_admin', null),
  ('<auth.uid of branch admin>', 'admin.andheri@aurora.test', 'Andheri Admin', 'branch_admin', '11111111-1111-1111-1111-111111111111'),
  ('<auth.uid of teacher>', 'teacher.1@aurora.test', 'Class 5A Teacher', 'teacher', '11111111-1111-1111-1111-111111111111'),
  ('<auth.uid of parent>', 'parent.1@aurora.test', 'Arjun Sharma', 'parent', '11111111-1111-1111-1111-111111111111');

Test passwords for development only: use Aurora-Test-2026 or similar. Never reuse on production. Save to VaultMate under category "Test Account."

Once seeded, you can log in as each persona separately to verify the right page renders and RLS isolates the data correctly.

The "Surprise" Permission Cases

Real schools have edge cases that don't fit a clean matrix. Decide upfront how you'll handle them:

Edge case	Recommendation
Parent has children in 2 different branches	Two `parent.children` relationships — one row per child. UI shows a branch dropdown if >1 child.
Teacher transfers branches mid-year	Change `profiles.branch_id`. Past attendance records keep their original `branch_id` — they're already scoped to a section.
A child changes from one section to another	Add `student_section_history` table for the audit trail. The `students.section_id` is "current section."
Two siblings share one parent	One `parents` row, two `students` rows both with same `parent_id`.
A super admin temporarily acts on behalf of a branch admin	Don't fake it. Super admins inherently see everything; they don't need to "switch."

These decisions matter because they shape your foreign keys.

What's Next

Now you have:

The 12-table schema (from the previous page).
The full permission matrix.
Test users seeded.
Per-persona routing decided.

Time to build the first module. Students is the right first module — every other module references students.

Personas & Permissions

The Five Personas

The Full Permission Matrix

How Each Persona Logs In

Creating Test Users (Seed Script)

The "Surprise" Permission Cases

What's Next

Next: Module · Students

On this page

Personas & Permissions

The Five Personas

The Full Permission Matrix

How Each Persona Logs In

Creating Test Users (Seed Script)

The "Surprise" Permission Cases

What's Next

Next: Module · Students

On this page