Notification Administrator Experience
Summary
An administrator has two screens: the Notification Center operations console reading the extracted service, and the template editor writing the legacy model. The console offers exactly one write action — retry.
Audience
Engineers, QA, support, HR administrators, DevOps engineers and architects.
Notification Center
A read-oriented console assembled from four parallel calls: the legacy template list, the extracted service's failed queue capped at 100, its audit trail capped at 100, and its statistics.
Only the template call is unguarded. The three extracted-service calls each carry an independent empty fallback, so the console still renders when the extracted service is unreachable — showing empty panels rather than an error.
Panels rendered:
| Panel | Content |
|---|---|
| Failed Notifications | Failed deliveries with a retry action per row |
| Notification Templates | Event, channel, version and active status, read-only |
| Notification Audit | Stage, message, correlation and occurrence, read-only |
The screen header describes it as covering templates, failed deliveries, retry status, channels and audit.
The retry action
The single write available. Posting the retry for a row shows a success toast reading that the retry was queued.
Two verified mismatches are worth an administrator knowing:
The wording is misleading. The underlying endpoint re-drives the message synchronously through the bounded delivery loop. Nothing is queued. The toast is optimistic and fires without inspecting the outcome.
The result is not refreshed. The screen does not reload after a retry, so the failed list still shows the row regardless of whether the retry succeeded. An administrator must refresh manually to see the effect.
Mixed data sources in one view
The template panel displays the legacy template list, but its column headers read event, channel, version and active — fields belonging to the extracted model. The row rendering falls back across both shapes, reading a template key or an event key for the first column.
The practical effect is that channel and version columns render empty for legacy rows, because the legacy model has neither. An administrator sees a table whose columns imply a model the data does not have.
Template administration
Covered in template management. Reached from two navigation groups pointing at one route, available in both the client and super-admin portals.
What an administrator cannot do
| Capability | Available |
|---|---|
| View failed deliveries and audit | Yes |
| Retry one failed message | Yes |
| Edit legacy templates, preview and reset | Yes |
| View extracted-service templates | Read-only |
| Edit extracted-service templates | No |
| Bulk-retry the failed queue | No |
| Filter, search or date-range the failed or audit lists | No |
| Page beyond the first 100 rows | No |
| Manage recipient preferences | No |
| Send a test notification | No UI — API hooks exist |
| See per-channel delivery health | No |
| Configure channels or providers | No |
Permissions
Menu visibility is gated on a settings permission, a view-all permission and an HR administrator role. As recorded in the API documentation these are client-side hints; the extracted service enforces nothing, and the legacy template controller requires authentication without a role check.
Classification
Transitional.
Requires confirmation
Whether the retry wording should be corrected, and whether extracted-service template editing is planned, require confirmation.
Related Articles
See Also
Keywords
- Notification database
- Administrator Experience
- Draft database documentation
Source References
UI/salary-ui/apps/client-hrms-portal/src/pages/admin/OperationsAdminPages.tsxUI/salary-ui/apps/client-hrms-portal/src/pages/admin/NotificationTemplateManagementPage.tsxmicroservices/src/notification-service/Api/NotificationEndpoints.csUI/salary-ui/apps/client-hrms-portal/src/components/AppLayout.tsx
Revision Information
- Status: Draft
- Last reviewed: 2026-07-21
- Review cycle: Quarterly