---
title: Access controls
category: security
order: 2
lastUpdated: 2026-06-08
featureAvailability: GA
roles: [admin, district-admin]
navigationPath: Administration → Users
relatedArticles: [getting-started/roles, security/data-encryption, procurement/audit-logging, procurement/identity-sso]
---

## 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](/help/procurement/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](/help/getting-started/roles).

## 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

- [Roles & permissions](/help/getting-started/roles)
- [Data encryption](/help/security/data-encryption)
- [Audit logging](/help/procurement/audit-logging)
- [Identity & SSO](/help/procurement/identity-sso)

## 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.