Notification Scenarios
Feature Detail
Description
Notification Scenarios provides a configurable rule engine that defines which platform events trigger which notifications, for which user roles, and via which channels. Scenario templates map business events (activity overdue, assignment dispatched, certificate expiring) to notification payloads and delivery rules. This decouples notification delivery from hardcoded event logic, enabling organizations to configure their own alert workflows without code changes or a new platform release.
Sources & reasoning
Blueprint marks notification-scenarios [v1.0], Fase 2. The HLF passage explicitly names scenario-based push as the solution to follow-up quality issues. A configurable scenario engine is the architectural expression of that requirement, enabling per-org rules without code branches per tenant.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
Different organizations have materially different notification needs: HLF requires scenario-based push for peer mentor follow-up, Blindeforbundet needs assignment dispatch alerts with read confirmation, and Barnekreftforeningen needs caregiver contact reminders. A configurable scenario system lets each organization define alert workflows without platform releases. This directly addresses the 40% follow-up dissatisfaction at HLF and supports the multi-tenant module toggle architecture by making notification behavior org-configurable rather than hardcoded per tenant.
Implement a notification_scenario_templates table storing event type, trigger conditions, target role filter, message template strings, and channel configuration per organization. A backend event bus (or post-save hooks on key domain entities) evaluates active templates and enqueues matching notifications asynchronously. Templates use simple variable substitution ({contact_name}, {activity_date}) resolved at send time. The admin portal exposes a scenario configuration UI for org admins. Per-org template sets are strictly isolated to prevent cross-tenant leakage. Scenario evaluation must be async and non-blocking relative to the primary write path.
Components (49)
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.