Feature Toggles

The four participating organizations have materially divergent feature needs - encrypted assignments are critical for Blindeforbundet but irrelevant to others; expense reimbursement is mandatory for HLF and Blindeforbundet but not for Barnekreftforeningen. Rather than maintaining per-organization code forks, the toggle system allows a single codebase to serve all tenants with appropriate scope. This directly enables the multi-tenant business model, keeps maintenance overhead low, and allows new organizations to onboard by configuration rather than code changes, making the platform commercially scalable.

The module_toggles table stores one row per area per organization with an enabled boolean. The API bootstrap endpoint includes the full enabled module set; clients mount only enabled area modules at runtime without compile-time switching. Backend route handlers check the tenant's enabled set before executing module-scoped operations. The admin UI lists all toggleable areas with human-readable names, current state, and dependency warnings (enabling an area that requires another auto-enables the dependency with a visible notification). Always-on modules are displayed as locked and excluded from the toggle editor to prevent the circular-dependency failure mode described in §4.