Skip to main content

Notification UI, Operations and Reference

Summary​

Complete Draft documentation for the Notification user interface, administrator experience and operational surface. Four notification screens and one header widget exist across two portals; all four read the legacy monolith paths except the operations console, which reads the extracted service. There is no preferences UI.

Audience​

Employees, HR administrators, support engineers, DevOps engineers, developers, QA engineers, solution architects and implementation partners.

Overview​

The Notification front end is delivered entirely inside the client HRMS portal, with one re-exported screen in the super-admin portal. Four route-level screens and one always-present header widget make up the surface.

Three characteristics define it and recur throughout this section:

  • The user-facing screens read the legacy path. The employee inbox, the header bell and the template administration screen all call the monolith's authenticated endpoints. Only the operations console reads the extracted service's administration endpoints.
  • Two different template models are edited and displayed. The template administration screen edits the legacy event-key model; the operations console displays the extracted service's versioned channel model read-only. They are different data.
  • Preferences have no UI. The preference table is read at dispatch time but has no management screen and no write path anywhere in the platform.

Operationally the service is a single .NET 8 process with one hosted consumer, JSON console logging, tracing without metrics, and a health endpoint that registers no checks.

Documentation map​

Start with the UI overview, then the screens: notification inbox, template management, dashboard integration and preferences.

Experience-level views are in user experience and administrator experience.

Operations are covered in operational architecture, configuration, monitoring, diagnostics, logging reference and health reference.

Support material is in troubleshooting, operational runbooks, FAQ, reference, UI limitations and the source map.

Classification​

Transitional. The inbox, template administration and operations console are Implemented; preferences UI, monitoring metrics and alerting are Not implemented; health checks and troubleshooting tooling are Partial.

Requires confirmation​

Whether the user-facing screens are intended to migrate to the extracted service, how notification permissions are enforced server-side, and the production observability destinations require confirmation.

See Also​

Keywords​

  • Notification UI
  • Operations
  • Draft UI documentation

Source References​

  • UI/salary-ui/apps/client-hrms-portal/src/pages/NotificationsPage.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/pages/admin/NotificationTemplateManagementPage.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/components/AppLayout.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/pages/admin/OperationsAdminPages.tsx
  • microservices/src/notification-service/Program.cs

Revision Information​

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