Ensure feature flags respect organization data isolation boundaries
All feature flag reads and writes must pass through Supabase RLS policies that restrict access to rows matching the authenticated user's organization. The feature-flag-repository must never perform queries without an organization scope predicate. The feature-flag-cache must be keyed by (organization_id, flag_key) to prevent cache poisoning across organizations. The rollout-evaluator must incorporate the organization_id in its deterministic hash to ensure cohort assignments are not shared across organizations. Integration tests must verify that a super-admin or cross-org scenario cannot read another organization's flags.
User Story
Acceptance Criteria
- Given user A belongs to Organization A and user B belongs to Organization B, when Organization A enables a feature flag, then the flag remains disabled for Organization B unless separately configured
- Given the feature-flag-repository executes a read query, when inspecting the generated SQL, then an organization_id filter is always present in the WHERE clause
- Given the feature-flag-cache stores a flag value, when the cache key is inspected, then it includes both the organization_id and the flag_key
- Given the rollout-evaluator assigns a user to an enabled cohort, when the same user switches organizations (multi-org scenario), then their cohort assignment is re-evaluated independently for the new organization context
- Given Supabase RLS policies are in place, when a request is made without a valid organization context, then the query returns zero rows and no flag data is exposed
- Given a system with two organizations, when Organization A's administrator views the feature flag admin screen, then no flags or audit entries from Organization B are returned from the repository
Business Value
Data isolation is a non-negotiable requirement for a multi-tenant platform serving NHF, Blindeforbundet, and HLF simultaneously. A breach of isolation — even unintentional — where HLF's feature configuration affects NHF's users would violate trust, potentially expose sensitive capability states, and undermine the entire multi-organization product strategy. RLS-enforced isolation is the architectural foundation of the platform's commercial viability.
Components
- Feature Flag Repository data
- Feature Flag Local Cache data
- Rollout Condition Evaluator service
- Feature Flag Provider infrastructure
- Feature Flag Key Constants infrastructure
- Supabase RLS Tenant Scope Configurator infrastructure
- Organisation Data Isolation Guard infrastructure