Access controls
Last updated 2026-06-08
At a glance
- Who uses it: Admins owning user lifecycle; security reviewers documenting access posture.
- When to use it: During onboarding, at every role change, and at quarterly access reviews.
- Permissions required: School admin (own school) or district admin (across schools).
- Navigation path: Administration → Users.
Purpose
Access controls describe how AmplifyED decides who can see and do what. This article is the operational counterpart to the procurement-facing Security overview.
Roles
- Super admin — AmplifyED platform staff. Filtered out of customer-facing lists.
- District admin — Full visibility across all schools in the district.
- School admin — Full control of one school: users, intake forms, attention rules, audit log.
- Facilitator — Owns assigned coaching cases. Sees their own caseload and the students attached to it.
- Teacher — Sees their own students, can submit referrals, can view limited case details and provide feedback.
See the full matrix in Roles & permissions.
How access is enforced
Every authorization decision is enforced server-side using a triple-gate pattern:
- Postgres row-level security on every domain table, scoped by
organization_id. - Server middleware that verifies the caller's session and attaches the authenticated org context.
- Server function assertion helpers (
is_org_member,is_org_admin,is_super_admin) that re-check membership and role before any read or write.
Client-side role checks are for UI affordance only and are never trusted for authorization.
Account hygiene
- Sign-in: Email + password (bcrypt), Google / Microsoft OIDC, or SAML 2.0 (Okta, Entra, OneLogin, generic).
- Failed sign-ins: 3 failures trigger an account lockout. Lockouts are audit-logged. An admin can clear a lockout.
- Session length: Configurable per org; default 12 hours.
- Idle timeout: Default 30 minutes; user is re-prompted to sign in.
- Deactivation: Toggle Active off on a user. Their session ends within minutes; their authored notes and case attachments are preserved.
Step-by-step
Change a user's role
- Administration → Users.
- Open the user.
- Click Change role. Pick the new role and confirm. The change is audit-logged.
[SCREENSHOT: admin-users-change-role-dialog] Administration → Users with the Change role dialog open and a confirmation summary on the right.
Run a quarterly access review
- Reports → Audit → Role changes for the last 90 days.
- Export to CSV.
- Reconcile against your district staffing list.
Related articles
FAQ
Can I create a custom role? Not at this time. The five built-in roles map to the access boundaries enforced at the database. Custom roles would require RLS changes; scoping is happening for a future release.
Are there read-only roles? The Teacher role is effectively read-only against case records (with the ability to submit feedback). For procurement reviewers who need read-only visibility into the platform, contact your account manager for a temporary scoped account.
Related
Roles & permissions
A clear matrix of what each role can see and do. | Role | Scope | Owns | | | | | | District admin | All schools | District reports, FERPA exports, audit | | Administrator | One…
Data encryption
Purpose: Document encryption at rest, in transit, and for sensitive credentials. TLS 1.2 or higher on every connection. HSTS enabled with preload eligibility. Certificate…
Audit logging
Who uses it: Admins responding to FERPA inquiries, security teams reviewing user activity, district leadership exporting evidence. When to use it: During access reviews, after a…
Identity & SSO (procurement)
Who uses it: District IT and identity team reviewing AmplifyED for procurement. Purpose: Summarize supported identity options, MFA posture, and provisioning behavior. OIDC —…
