All Docs
FeaturesCSI Teachable Replacement AppUpdated March 15, 2026

Admin Role Authorization & Permission Guards

Admin Role Authorization & Permission Guards

Available from: v1.0.78

The platform enforces a role-based access control (RBAC) model that separates Org Admin users from Learner Members. This ensures that sensitive administrative capabilities — such as course authoring, enrolment management, reporting, and identity provider configuration — are only accessible to authorised personnel within an organisation.

Roles

RoleDescription
Org AdminFull access to all platform areas including course builder, enrolments, reporting, and SSO settings. Can assign roles to other users within the organisation.
Learner MemberAccess restricted to the learner-facing experience: browsing available courses, completing enrolled content, and viewing personal progress.

Roles are scoped to a tenant organisation. A user may be an Org Admin in one organisation and a Learner Member in another.

Protected Areas

The following platform areas require the Org Admin role. Learner Members are blocked from accessing them — both via the UI and direct URL navigation.

Course Builder

Create, edit, structure, and publish courses including lessons, sections, attachments, and embedded media.

Enrollment Management

View and manage which learners are enrolled in which courses. Add or remove learners from cohorts and track enrolment status.

Reporting

Access analytics dashboards covering course completion rates, learner engagement, lesson-level progress, and SSO sign-in activity.

SSO Configuration

Configure identity provider (IdP) connections, manage SAML/OIDC settings, and map IdP attributes to platform user fields.

How Permission Guards Work

Permission checks are applied at two layers:

  1. Server-side (API & page routes): Every request to a restricted route is validated against the authenticated user's role before any data is fetched or returned. An unauthorised request receives a 403 Forbidden response.
  2. Client-side (UI): Navigation items and action buttons for restricted areas are conditionally rendered based on the authenticated user's role. Learner Members will not see admin-only menu entries.

Both layers must pass independently — the client-side guard is a UX convenience, not a security boundary.

Privilege Escalation Prevention

  • Users cannot self-assign the Org Admin role through either the UI or the API.
  • Role assignment is an admin-only action and is scoped to the user's own organisation — an Org Admin in Organisation A cannot modify roles in Organisation B.
  • All role-change events are validated server-side regardless of the request origin.

Managing Roles

Org Admins can assign or revoke roles for members of their organisation from the Members section of the admin dashboard:

  1. Navigate to Settings → Members.
  2. Locate the user whose role you want to change.
  3. Select their current role label and choose a new role from the dropdown.
  4. Confirm the change. The new role takes effect on the user's next request — no session invalidation is required.

Only Org Admins can access the Members settings page.

Behaviour for Learner Members

  • Admin-only navigation links (Course Builder, Enrolments, Reports, SSO) are not rendered in the sidebar or top navigation.
  • Attempting to navigate directly to a restricted URL (e.g. /admin/courses/builder) results in an immediate redirect to the learner dashboard — no partial page load occurs.
  • No error message exposes the existence or structure of admin-only routes.

Migration & Existing Users

  • All users who previously had admin access retain the Org Admin role automatically.
  • All other existing users are assigned the Learner Member role by default.
  • No re-login or session refresh is required — role checks apply to each incoming request.

Related Topics