Notification Settings

Giving users control over notification preferences is both a product-quality requirement and a regulatory obligation under GDPR and Norwegian ePrivacy rules - users must be able to withdraw consent for non-essential communications without being penalized in service access. From a retention perspective, users who receive irrelevant or excessive notifications at inconvenient times are more likely to disable all push notifications or delete the app entirely, destroying the notification channel for critical alerts. A well-designed settings screen also reduces support requests about unwanted alerts and builds user trust, which is particularly important for a platform handling sensitive personal data about vulnerable individuals.

Notification preferences are stored in the notification_settings table with one row per user, and a related notification_rules table for per-category channel overrides. The Flutter settings screen uses Riverpod state management, with changes written optimistically to the local Drift database and synced to the backend via the mutation outbox. Quiet hours are stored as UTC-offset time ranges and evaluated server-side before dispatch to avoid timezone edge cases. The settings schema is versioned so new notification categories can be added with a sensible default (typically enabled) without requiring a migration of existing user rows. The admin portal allows org admins to mark certain scenarios as mandatory, preventing users from disabling them - this flag is enforced server-side, not just in the client UI.