Custom Terminology
Feature Detail
Description
Custom Terminology allows each organization to override display strings used throughout the platform to match their own vocabulary. The platform default "Contact" becomes "Familie" for Barnekreftforeningen or "Bruker" for another org. Overrides are maintained in a server-side terminology registry and distributed to clients at session bootstrap, ensuring consistent language across mobile and web without separate builds or code changes per tenant.
Sources & reasoning
The source describes the Organization Labels system as an already-architected feature of the mobile app with three live keys. Phase 1 admin scope includes "terminologikonfigurasjon" as an MVP deliverable. This feature is the Admin Web Portal surface that lets Org Admins manage those overrides. Classified MVP because mismatched labels directly harm adoption.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
Each of the four partner organizations uses different vocabulary for the same roles and entities. Forcing a single terminology on all tenants creates friction, confusion, and reduced adoption - particularly for volunteer peer mentors unfamiliar with platform jargon. Mismatched terminology increases support tickets, slows onboarding, and risks misregistration of activities. Custom Terminology removes this barrier by letting admins align platform language with existing organizational culture. It also future-proofs tenant onboarding: new organizations brand the platform to their vocabulary without any engineering work, making commercial scaling a configuration task rather than a development task.
Terminology overrides are stored in the terminology_overrides table keyed by organization_id and a closed term-key enum. The backend includes the full override map in the session bootstrap response. The Flutter mobile app caches overrides in Drift for offline use. The Admin Web Portal renders a terminology configuration table showing overrideable keys with current values and platform defaults as placeholders. Keys are server-defined (closed set) to prevent arbitrary string injection. Initial keys: contacts, my_contacts, peer_mentors, peer_mentor, coordinator, contact. Resetting to default is a distinct action. Changes take effect on next client session without an app release.
Components (46)
Shared Components
These components are reused across multiple features
Service Layer (11)
Data Layer (23)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.