Skip to main content

Notification Preferences

Summary​

There is no notification preferences user interface. No screen, route, navigation entry, drawer, modal or control anywhere in either portal creates, edits or displays a notification preference.

Audience​

Engineers, QA, support, employees, administrators and product owners.

Verified absence​

  • No preferences route in either portal's route table.
  • No navigation entry referencing notification preferences.
  • No preference control on the inbox, the drawer, the template screen, the operations console or any settings screen.
  • No API call to any preference path from any front-end file.
  • No preference endpoint exists on the extracted service or the legacy controllers to call.

The search covered both portals across all TypeScript and React sources.

What exists behind the missing UI​

The extracted service stores per-recipient channel opt-outs and enforces them at dispatch time. A preference evaluator loads candidate rows for the tenant, recipient and channel and resolves an exact event-type match ahead of a wildcard row; absence of a row means enabled, so notifications flow by default.

A suppressed channel is audited and contributes a suppressed outcome to the event.

The enforcement half is fully implemented. The management half does not exist at any layer — not in the UI, not in the API, and not in any seeder or administrative tool. Rows can only be created directly in the database.

Consequence​

Neither an employee nor an administrator can silence a channel, opt out of an event type, or see what preferences apply to them. The capability is invisible from every surface a user can reach.

Because absence of a row means enabled, the practical effect today is that every recipient receives every notification on every default channel for their events, with no opt-out path.

The per-event channel override map is a configuration setting rather than a preference, and likewise has no UI. Changing which channels an event uses requires a configuration change and a restart.

Classification​

Not implemented — the user interface. Enforcement is Implemented; see the technical and database sections.

Requires confirmation​

Whether preference management is planned, at which layer, and whether it is intended to be employee self-service or administrator-managed, all require confirmation.

See Also​

Keywords​

  • Notification database
  • Preferences
  • Draft database documentation

Source References​

  • microservices/src/notification-service/Application/PreferenceEvaluator.cs
  • microservices/src/notification-service/Domain/NotificationEntities.cs
  • microservices/src/notification-service/Api/NotificationEndpoints.cs
  • UI/salary-ui/apps/client-hrms-portal/src/pages/NotificationsPage.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/components/AppLayout.tsx

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly