VENI-AI

English

Tiếng Việt

English

Tiếng Việt

Appearance

Feature Specification: In-App Notification Center ​

1. Overview & Vision ​

The Notification Center surfaces real-time HRM events to the right people without requiring them to navigate to find updates. Key workflow events — status changes, pending reviews, leave decisions — are delivered as in-app notifications.

2. Personas & Stakeholders ​

PersonaGoal
EmployeeKnow immediately when their leave is approved or rejected.
ManagerGet notified when a team member submits a leave request or changes status.
HR AdminReceive alerts for onboarding submissions ready for review.

3. User Stories ​

  • As an employee, I want to see a badge on the bell icon when my leave request is decided.
  • As a manager, I want a notification when a direct report submits a leave request so I don't miss it.
  • As HR, I want to be notified when a candidate completes their magic-link self-submission.

4. Functional Requirements (FR) ​

  • REQ-NOT-001: Notification bell icon in the HRM header with unread count badge.
  • REQ-NOT-002: Notification panel — list of recent notifications with timestamp and read/unread state.
  • REQ-NOT-003: Mark as read (individual) and Mark all as read.
  • REQ-NOT-004: Notification types:
    • Leave request submitted (→ approver)
    • Leave request approved / rejected (→ employee)
    • Employee status transition (→ HR Admin)
    • Onboarding submission ready for review (→ HR Admin)
    • Late check-in detected (→ manager)

5. Non-Functional Requirements (NFR) ​

  • Delivery: Notifications delivered within 5 seconds of the triggering event.
  • Persistence: Notifications stored in DB; survive page refresh and re-login.

6. Business Logic & Rules ​

  • Targeting: Each event type has a defined recipient rule (e.g., leave submission → all approvers in the chain).
  • Deduplication: Repeated events for the same entity within 60 seconds are collapsed into one notification.
  • Retention: Notifications older than 90 days are auto-archived.

7. User Interface (UI/UX) ​

  • Bell icon in the top-right of the HRM header with an unread count badge (capped at 99+).
  • Dropdown panel: scrollable list, each item shows icon, title, description, relative timestamp.
  • Click-through: Clicking a notification navigates to the relevant record (leave request, employee profile, etc.).

8. Information Architecture ​

  • Notification bell is always visible in the HRM layout header.
  • Full notification history accessible via "See all notifications" link in the panel.

9. Data Model & Persistence ​

  • Table: notifications (recipient_id, type, title, body, entity_type, entity_id, read_at, created_at).

10. API & Service Layer ​

  • GET /notifications?unread=true
  • POST /notifications/:id/read
  • POST /notifications/read-all
  • Notifications created internally by service layer (not a public endpoint).

11. Integration Patterns ​

  • Event-driven: Listens to internal service events (LEAVE_SUBMITTED, LEAVE_DECIDED, EMPLOYEE_STATUS_CHANGED, ONBOARDING_SUBMITTED, ATTENDANCE_LATE).
  • Shell bus: Future integration to push notifications to the Shell notification center for cross-module visibility.

12. Security & Permissions ​

  • Users can only read their own notifications.
  • No cross-org notification delivery.

13. Error Handling & Resilience ​

  • Failed notification delivery is retried up to 3 times with exponential backoff.
  • Missing entity (deleted leave request) renders notification with a "Record no longer available" message.

14. Performance & Scalability ​

  • Unread count is cached per user in Redis; invalidated on new notification or mark-as-read.
  • Notification list is paginated (20 per page).

15. Globalization & i18n ​

  • Notification titles and body text rendered in the recipient's preferred language (EN/VI).

16. Accessibility (a11y) ​

  • Bell icon announces unread count via ARIA live region.
  • Panel is keyboard-navigable (Tab through items, Enter to navigate, Esc to close).

17. Observability & Analytics ​

  • Notification delivery latency tracked per event type.
  • Open rate (click-through vs. delivered) per notification type.

18. Testing & Quality ​

  • Unit tests for recipient resolution logic per event type.
  • Integration tests for event → notification creation → read flow.

19. Constraints & Assumptions ​

  • Real-time delivery uses polling (500ms interval) in v1; WebSocket upgrade planned for v2.

20. Future Enhancements ​

  • Push notifications (browser / mobile PWA).
  • Email digest for low-urgency notifications.
  • WebSocket-based real-time delivery.

© 2025-2026 VENIZIA AI