View and Select My Organization on App Launch
When a peer mentor opens the app and has completed authentication, they are presented with the Organization Selection Screen listing all organizations they are a member of. Each organization is displayed as a card showing the organization name, logo, and their role within that organization. Tapping a card sets the active tenant context for the entire session, loading organization-specific terminology, branding, feature flags, and data scope. This screen uses the 001-org-selection-screen and 665-org-selection-screen components backed by the 003-org-selection-service and 670-org-selection-service for fetching memberships, and 004-org-persistence-repository / 673-organization-repository for storing the selection.
User Story
Audience Summaries
The organization selection screen is the foundational gateway that enables peer mentors serving multiple organizations — including NHF members belonging to up to five local chapters — to correctly scope their work, data, and reporting. Without this critical entry point, cross-organization data leakage becomes inevitable, Bufdir compliance reporting breaks down, and the platform cannot be trusted by any of the founding organizations. Delivering this story correctly protects the contractual integrity of the entire platform, directly enabling customer retention and trust across all partner organizations. It also future-proofs the platform for onboarding additional multi-chapter organizations, representing a key competitive differentiator in the Norwegian nonprofit sector.
This is a critical-priority story that gates the entire authenticated user experience — all downstream feature development depends on a working tenant context. Delivery requires close coordination between backend (membership API, persistence layer), frontend (Flutter card UI, branding integration), and QA (multi-org test accounts, network error simulation). The auto-selection logic for single-org users and the branding-per-org requirements add non-trivial edge case coverage. Acceptance criteria include six distinct scenarios spanning happy path, error handling, auto-selection, and persistence, all of which require dedicated test cases.
Rollout risk is high given its role as a session initialization bottleneck — any regression here blocks all users. Smoke testing and regression coverage must be prioritized before each release.
Implementation centers on the 001-org-selection-screen and 665-org-selection-screen UI components rendering organization cards with name, logo, and role. The 003-org-selection-service and 670-org-selection-service handle membership fetching, while 004-org-persistence-repository and 673-organization-repository manage local selection persistence. Key technical concerns include: setting the active tenant context globally at session start (feature flags, terminology, branding, data scope), handling the single-org auto-selection branch without flickering, graceful network error recovery with retry, and correct cache invalidation on membership changes. Branding data (colors, logo) must be loaded asynchronously without blocking card render.
Local persistence must be invalidated if membership changes between sessions. Performance of the initial load is critical as it directly impacts perceived app launch time.
Acceptance Criteria
- Given I have authenticated and belong to one or more organizations, When the org selection screen loads, Then I see a card for each organization I am a member of, showing the organization name and my role
- Given the org selection screen is displayed, When I tap an organization card, Then the app navigates to the role-based home screen for that organization and all subsequent data is scoped to that organization
- Given I belong to only one organization, When I authenticate, Then the app may auto-select that organization and skip the selection screen, navigating directly to the home screen
- Given I am on the org selection screen, When the organization list fails to load due to a network error, Then I see a clear error message with a retry option
- Given the org selection screen loads, When organization branding data is available, Then each card renders the organization's colors and logo if configured
- Given I am on the org selection screen, When I select an organization, Then the selection is persisted locally so that on subsequent app launches I am not required to re-select if my membership has not changed
Business Value
The organization selection screen is the critical entry point that establishes the entire data and access scope for a user session. Without it, peer mentors operating across multiple organizations — a real scenario described in the workshops where NHF members can belong to up to 5 local chapters — would have no mechanism to isolate their work correctly. Incorrect organizational attribution leads to compliance failures, data leakage between organizations, and broken Bufdir reporting. Getting this right at session start protects data integrity for all downstream features.
Components
- Organization Selection Screen ui
- Organization Card Widget ui
- Organization Selection Service service
- Organization Persistence Repository data
- Local Storage Adapter infrastructure
- Organization Labels Provider infrastructure
- Organization Selection Screen ui
- Organization Card Widget ui
- Tenant Context Service service
- Organization Selection Service service
- Organization Route Guard service
- Multi-Organization Membership Resolver service
- Organization Repository data
- Tenant Session Store data
- Organization Branding Cache data
- Secure Storage Adapter infrastructure
- Supabase RLS Tenant Scope Configurator infrastructure