Access controls

Last updated 2026-06-08

View raw markdown

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:

  1. Postgres row-level security on every domain table, scoped by organization_id.
  2. Server middleware that verifies the caller's session and attaches the authenticated org context.
  3. 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

  1. Administration → Users.
  2. Open the user.
  3. 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

  1. Reports → Audit → Role changes for the last 90 days.
  2. Export to CSV.
  3. 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