Skip to main content

Notification

Summary​

HR Suit has a Transitional notification capability spanning an extracted event-driven service and an authenticated legacy application path. It provides a persisted in-app inbox, configurable email delivery, template rendering, delivery attempts, retry, audit history, read state and operational summaries. SMS and WhatsApp are represented but do not have real external providers in the reviewed source.

Audience​

Business users, managers, HR and tenant administrators, product owners, implementation partners, QA, support, security reviewers and solution architects.

Overview​

This business set covers notification scope, lifecycle, channels, templates, delivery, retry, history, employee and administrator experiences, reporting, rules, integrations, compliance, limitations and source traceability.

Business Purpose​

Turn significant HR events into traceable messages for employees and operational teams while keeping message wording and delivery concerns outside originating modules.

Actors​

Employees, managers, HR and tenant administrators, super administrators, originating-module owners, support teams, product owners and security reviewers.

Business Flow​

An originating module emits a supported event. The service resolves recipients and channels, applies preferences, selects and renders a template, persists a message, attempts delivery and records processing and audit outcomes. Employees read current and legacy in-app records through a unified inbox; administrators manage or monitor different capabilities through separate UI paths.

Responsibilities​

Originating modules provide supported, tenant-aware event and recipient data. Product and tenant owners govern content and channels. Employees manage read state. Operations teams investigate failures and use retry carefully. Platform owners must reconcile the two implementations and enforce access and privacy controls.

Business Rules​

Processing is idempotent by event identifier; tenant templates override global templates; missing preferences mean enabled; delivery attempts are append-only; and message creation does not guarantee successful external delivery. The business-rule catalog is authoritative.

Integrations​

The extracted service consumes events from Employee, Leave, Payroll, Document, Platform, Expense, Asset, Performance, Training and Helpdesk domains. The portal also uses legacy notification and template endpoints from the main application.

Limitations​

The implementations have different template models and endpoint contracts. Workflow and most Recruitment events are not in the extracted resolver. SMS and WhatsApp only simulate delivery, email depends on provider configuration, preferences lack a reviewed user-facing management path, and extracted-service endpoint authorization is not evident.

Requires Confirmation​

Production provider selection, event ownership, canonical template system, access enforcement, retention, consent, localization, escalation targets, service-level objectives and migration from legacy records require confirmation.

Source References​

  • microservices/src/notification-service/Application/NotificationDispatcher.cs
  • microservices/src/notification-service/Application/EventNotificationResolver.cs
  • microservices/src/notification-service/Channels/ChannelSenderRegistry.cs
  • Controllers/NotificationsController.cs
  • Controllers/NotificationTemplatesController.cs
  • UI/salary-ui/apps/client-hrms-portal/src/pages/NotificationsPage.tsx

See Also​

Keywords​

Notification, event, inbox, template, delivery, retry, audit.

Revision Information​

Draft source-backed business documentation reviewed on 2026-07-21; next quarterly review is 2026-10-21.