LMS
Back to home
Platform administration

Feature flags

Two layers, not one. A superadmin grants which features a tenant is allowed to use at all - platform entitlements, managed from the Tenants page's "Flags" dialog on each tenant's row, covered on this page. A tenant admin then separately turns granted features on for their own workspace, on their own Feature settings page - a granted-but-not-yet-turned-on feature stays off by default, same as an ungranted one, just without the "ask your platform administrator" message.

What's configurable

Enable AI features

Off by default for every tenant. Controls whether that tenant's instructors can use AI-assisted authoring in the Course Builder Studio - generating lesson content and diagrams from a prompt. When off, those entry points don't appear in the Studio at all (no disabled/grayed-out state); the backend also rejects the underlying API calls, so this can't be bypassed from the client.

Knowledge base

A family of flags gating the RAG pipeline (see Knowledge base & Ask about this course), each off by default:

  • Documents in knowledge base - whether instructors can upload new course documents for ingestion. Turning this off only blocks new uploads; already-uploaded documents stay listable/previewable/ deletable.
  • Knowledge base for generation - whether the AI content-generation routes (lesson content, diagrams, exam questions, etc.) retrieve course material to ground their output. Not a hard gate like the other two - with this off, generation still works, it just never gets course-material grounding.
  • Learner Q&A - whether the "Ask about this course" widget's backend route is reachable at all. The widget itself also checks this flag client-side and renders nothing when it's off, but that's a UX nicety - the route enforces it regardless.

Learners read published versions

Off by default. A single flag, not a family like Knowledge base - there is no tenant-admin opt-in layer under it. When on, a member's course/module/lesson/exam reads (and lesson completion, progress, and practice-answer saves) come from the last published version rather than the working copy an instructor may still be editing; an instructor's own reads are unaffected (they always see the working copy, plus a ?view=published toggle in the Studio to preview what learners see). See Course Builder Studio for what publishing means with this on, and docs/ADR.md's ADR-074 for the full design. Off, a tenant's published courses behave exactly as before this feature existed - an edit reaches learners the moment it's saved.

Enable social login

Off by default. Lets a tenant admin choose which social login buttons (Google, Apple - the only two the platform currently supports) their own members see on the mobile app's sign-in screen, from their own Feature settings page. Cosmetic gating only - it decides which buttons render, not which sign-ins Cognito itself will accept (see docs/ADR.md's ADR-058). See Signing in for what a member actually sees.

How it's stored

Tenant flags live in one JSONB column (tenants.flags), the same storage shape branding uses - a free-form dict validated only at the API boundary, not a column per flag. Adding a new flag later needs no schema change, just a new key.