Notification Overview
Business Purpose
Provide a plain-language inventory of what stakeholders can rely on today and what remains transitional.
Actors
Employees, notification administrators, operations teams, module owners and implementation partners.
Business Flow
The capability covers event intake, recipient resolution, opt-out evaluation, template selection, token rendering, message persistence, channel dispatch, retry, attempts, audit, statistics and employee read state.
| Capability | Source-backed status | Business interpretation |
|---|---|---|
| In-app messaging | Implemented | A sent in-app message is persisted for inbox retrieval. |
| Configuration-dependent | Real external delivery requires the selected provider and valid recipient data. | |
| SMS and WhatsApp | Foundation only | Senders simulate/log success; no external provider is implemented. |
| Templates | Implemented in two models | Extracted service versions by key/channel; legacy application edits eight event-key records. |
| Preferences | Backend foundation | Evaluation and persistence exist; no reviewed self-service UI/API path. |
| Retry and audit | Implemented | Attempts, failure state, manual retry and processing audit exist. |
| Employee inbox | Implemented through legacy application | Current and legacy records are combined for the signed-in active user. |
Responsibilities
Product owners define what each status means operationally. Administrators must not infer external delivery from a simulated channel. Support teams correlate event, message, attempt and audit data before communicating outcomes.
Business Rules
The channel label alone does not prove provider delivery. The employee inbox returns records belonging to the authenticated active user and combines two legacy data sets.
Integrations
The service integrates through business events and channel senders; the portal integrates through notification, template, audit, failed-message and statistics operations.
Limitations
Read-state behavior differs between extracted and legacy stores. There is no reviewed delivery receipt from external recipients, and “Sent” can mean provider acceptance or simulated success depending on configuration.
Requires Confirmation
Confirm production channel configuration, the authoritative inbox store, support terminology for sent versus delivered, and the retirement plan for legacy records.
Source References
microservices/src/notification-service/Domain/NotificationEntities.csmicroservices/src/notification-service/Channels/EmailSenders.csmicroservices/src/notification-service/Channels/PlaceholderSenders.csControllers/NotificationsController.cs
Related Articles
See Also
Keywords
Capabilities, implementation status, inbox, provider.
Revision Information
Draft; reviewed 2026-07-21; next quarterly review 2026-10-21.