See org-specific dynamic fields tailored to my organisation in the report
Each organisation (NHF, Blindeforbundet, HLF) has different report structures. Blindeforbundet needs fields for health status, course interest, assistive device situation, and way-forward. HLF may have different or fewer required sections. NHF has specific needs around cognitive accessibility and multi-chapter contexts. The report schema service fetches the organisation's field configuration and the dynamic field renderer builds the form accordingly. Cached schema data allows the form to work offline for peer mentors in areas with poor connectivity.
User Story
Audience Summaries
This story directly enables multi-tenant commercial viability across NHF, Blindeforbundet, and HLF without duplicating the codebase. Each organisation operates under distinct Bufdir reporting mandates, internal workflows, and data collection requirements — a single rigid form would either burden peer mentors with irrelevant fields or fail to capture critical organisation-specific data. By delivering a schema-driven dynamic field system, the platform becomes a single deployable product that can serve all three organisations simultaneously, dramatically reducing maintenance overhead, accelerating onboarding of future partner organisations, and protecting data quality at scale. High-quality, organisation-relevant data directly improves reporting compliance, strengthens relationships with each organisation's leadership, and supports grant retention.
Offline schema caching further ensures peer mentors in low-connectivity areas — a real operational constraint — can continue working without interruption, protecting session continuity and data capture rates.
This is a high-priority, architecturally significant story that introduces a configuration-driven form rendering system. Delivery requires close coordination between product, backend, and mobile teams: the report schema service must be designed and deployed before the dynamic field renderer can be built and tested. Schema caching for offline support adds an additional layer of complexity requiring cross-platform testing on iOS and Android in simulated offline conditions. Acceptance criteria span five distinct scenarios including offline fallback, terminology overrides, and live admin-driven schema updates — each requiring dedicated QA cycles and sign-off from organisation representatives at NHF, Blindeforbundet, and HLF.
Stakeholder involvement from each organisation's admin team is essential to validate their specific field configurations. Timeline risk is moderate: the schema service dependency is a hard blocker. Plan for at least one round of organisation-specific UAT before release. Rollout should be phased per organisation to catch configuration issues early.
Implementation requires two primary systems: a report schema service and a dynamic field renderer. The schema service must expose a per-organisation field configuration API (fields, labels, sections, visibility rules, terminology overrides) and support ETags or versioned responses for cache invalidation. The mobile client must persist the fetched schema to local storage (AsyncStorage or SQLite) with a timestamp for staleness checks, and display an offline indicator when serving cached data. The dynamic field renderer must interpret the schema at runtime to construct form sections, apply org-specific label strings, and enforce field-level validation rules.
Field types (text, select, checkbox, list) must be handled generically. The offline-first architecture requires careful handling of the cache refresh lifecycle: fetch on mount if online, fall back to cache if offline, refresh cache on next successful connection. Edge cases include schema version mismatches, empty field configs, and terminology keys missing from the config. Unit tests should cover schema parsing, offline fallback logic, and label override application.
Integration tests should validate full form rendering per organisation config.
Acceptance Criteria
- Given a peer mentor from Blindeforbundet opens the post-session report, when the form loads, then only Blindeforbundet-configured sections and fields are displayed
- Given a peer mentor from HLF opens the post-session report, when the form loads, then only HLF-configured sections are shown with HLF-specific terminology
- Given the device is offline when the peer mentor opens the report form, when the cached schema is available, then the form loads using the cached configuration with an offline indicator shown
- Given org-specific terminology is configured (e.g., 'contact' vs 'recipient'), when the report form renders field labels, then the org-specific term is used throughout
- Given the org field configuration is updated by an admin, when the peer mentor next loads the report form with connectivity, then the updated schema is fetched and the cache is refreshed
Business Value
Each organisation has distinct reporting needs shaped by their workflows, Bufdir requirements, and operational structure. A one-size-fits-all report form would either overwhelm peer mentors with irrelevant fields or omit critical organisation-specific data. Dynamic org-configured forms ensure high data quality and relevance, reduce cognitive load, and make the app viable for a multi-tenant deployment across NHF, Blindeforbundet, and HLF without forking the codebase.
Components
- Post-Session Report Screen ui
- Dynamic Field Renderer ui
- Report Schema Service service
- Report Schema Cache data
- Organisation Field Config Loader infrastructure
- Terminology-Aware Text Widget ui
- Organization Labels Notifier service
- Label Key Resolver Service service
- Terminology Repository data
- Terminology Local Cache Adapter data