Most access incidents begin with one sentence: "can you just give them access for now?" This page helps you answer that safely and quickly. It explains how Classia uses account and role boundaries so sensitive details stay with the right people. You can use it for weekly reviews, staff handovers, and support escalations.
Start with the mistake we see most
Giving broad admin access feels efficient in a busy week. Then a teacher accidentally edits enrolment records, or a former staff member still appears in account users, and the studio has to unwind the damage.
A better pattern is simple:
- keep admin roles tight,
- use scoped roles for teaching and portal use,
- remove unused access quickly.
How account access works in practice
Classia checks two things for sensitive actions:
- admin role in the active account,
- the person or item being viewed belongs to that same account.
This is why queue and settings screens only show account-specific data, not system-wide lists.
If someone changes active account context, visibility changes with it. This is why "I cannot see that profile anymore" is often normal and correct, not an error.
Role boundaries that protect operations
Admin
Admin role handles high-impact operations: settings changes, enrolment request decisions, user and invite management, payment configuration, and broader data correction.
Teacher, parent, and participant in portal contexts
Portal access for these roles is narrower by design. Portal screens show only data linked to that role and account.
Admin memberships are redirected to the main dashboard for admin workflows rather than using portal pathways.
Invites and membership controls
In current settings flow, invites sent from Settings > Users create admin invites. This should be treated as a controlled action.
Operational points:
- pending invites can be resent or revoked,
- invites expire and should be reviewed weekly,
- membership removal also clears that user’s account sessions,
- last-admin removal is blocked.
Example: small dance school handover
A school with 3 office staff replaces one admin. They send one admin invite, wait for acceptance, then remove the old admin. No shared password is used and no gap in admin coverage occurs.
Example: teacher access request mid-term
A teacher asks for admin access to fix a class list quickly. Studio keeps teacher in scoped role and routes data fix through admin owner. This avoids ad-hoc permission creep.
Example: stale invite after staffing change
A pending invite sits for 12 days after a cancelled hire. Admin revokes it during weekly access review to reduce open invitation risk.
Access audit checklist for Fridays
Use this 10 to 15 minute routine:
- list current admin memberships,
- confirm no departed staff remain active,
- review pending invites older than seven days,
- confirm portal role links look sensible,
- document unusual exceptions.
This one routine catches most access drift before it becomes an incident.
Pitfalls to avoid
- Treating admin as a default role for trusted staff.
- Leaving pending invites unowned for weeks.
- Forgetting that portal users and admin users have different visibility boundaries.
- Removing an admin before another admin is active.
- Diagnosing scope-based visibility as a bug without checking account context first.