Notification UI Overview

Summary

Four route-level screens and one header widget. Three navigation entries plus one self-service entry. One screen is re-exported into the super-admin portal.

Audience

Engineers, QA, support, architects, HR administrators and implementation partners.

User navigation

Routes

Route	Screen	Portal
/notifications	Employee inbox, split by audience	Client HRMS
/settings/notification-templates	Template administration	Client HRMS and Super Admin
/operations/notifications	Notification Center operations console	Client HRMS

All three are wrapped in the portal's protected-page guard. There is no unauthenticated notification route.

The audience split

The inbox route renders one of two components through an audience helper: an employee-only user receives the generic self-service list, and any other user receives the full-featured inbox screen. The two are materially different — the self-service variant is a generic list component configured with four fields, while the full screen has filters, categorisation and per-item actions.

This means the richer inbox is shown to non-employee-only users, which is worth noting because the screen's own heading describes itself as employee self-service.

Navigation entries

Entry	Group	Path	Declared permissions	Declared roles	Audience
Notifications	Self Service	/notifications	Self-scoped view permission	—	Employee
Notification Center	Operations	/operations/notifications	Settings and view-all permissions	HR administrator	Admin
Notification Templates	Operations	/settings/notification-templates	Settings permission	HR administrator	Admin
Notification Templates	Settings	/settings/notification-templates	Settings permission	HR administrator	Admin

The template screen is registered twice, once under Operations and once under Settings, both pointing at the same route. Users with the relevant role see the same destination in two places.

These declarations gate menu rendering only. As recorded in the API documentation, no corresponding server-side check exists on the extracted service, and the legacy template controller requires authentication without a role check.

Portals

The client HRMS portal owns every screen. The super-admin portal contains a notification template page that is a one-line re-export of the client portal component — the same screen, mounted in a second shell, calling the same endpoints.

Backend split

Screen	Reads
Header bell and drawer	Legacy monolith paths
Employee inbox	Legacy monolith paths
Template administration	Legacy monolith template paths
Notification Center	Extracted service administration paths
Executive dashboard tiles	Extracted service statistics, failed and audit paths

Only the operations console and the dashboard read the extracted service. Everything a normal user touches reads the legacy path.

Verified absence

There is no notification preferences screen, no notification settings screen, no per-channel opt-out control, no notification search box, no date-range filter, no export control and no notification detail page.

Classification

Transitional.

Requires confirmation

Whether user-facing screens are intended to migrate to the extracted service requires confirmation.

Related Articles

• Notification inbox
• Template management
• Administrator experience

See Also

• UI limitations
• Dashboard integration

Keywords

• Notification database
• UI Overview Detail
• Draft database documentation

Source References

• UI/salary-ui/apps/client-hrms-portal/src/App.tsx
• UI/salary-ui/apps/client-hrms-portal/src/components/AppLayout.tsx
• 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/pages/admin/OperationsAdminPages.tsx
• UI/salary-ui/apps/client-hrms-portal/src/ess/EssPages.tsx
• UI/salary-ui/apps/super-admin-portal/src/pages/admin/NotificationTemplateManagementPage.tsx

Revision Information

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