Multi-Organization Hierarchy Management

Without a correct organizational hierarchy, the platform cannot serve multiple member organizations simultaneously, making this a foundational requirement. Each organization operates independently with its own settings, users, and data, yet the platform must support centralized Bufdir reporting and cross-organization administration. This feature directly enables the business model of selling a single shared platform to multiple organizations (NHF, Blindeforbundet, HLF, Barnekreftforeningen), reducing per-organization infrastructure cost and enabling economies of scale. Incorrect hierarchy handling would cause data leakage between organizations or prevent coordinators from managing their local associations, both of which are critical failures.

The hierarchy is modeled as organizations → regions → local_associations with foreign keys enforced at the PostgreSQL level. Row-level security (RLS) or application-level tenancy scoping ensures queries are always filtered by the authenticated user's organizational context. The REST API resolves the active tenant from the JWT claims (organization_id, role) and applies scope to every query. Flutter BLoC state holds the selected organization context and passes it as a header or path parameter on every API request. Admin panel uses Next.js middleware to enforce org-scoped data access. Migrations must seed the known hierarchy for all four organizations at deploy time.