Skip to main content

Leave Notification Integration Events

Summary​

Notification subscribes to LeaveApproved and LeaveRejected, resolves an employee notification intent, and owns templates, preferences, rendering, delivery, retries, audit, and idempotency.

Audience​

Leave/Notification developers, QA, architects, delivery owners, and support.

Concept​

The resolver uses Leave type, date, unit, and rejection-context categories to create an employee-directed intent. This guide intentionally omits personal details and rendered content. LeaveApproved and LeaveRejected have confirmed templates; no requested, cancelled, balance-updated, or encashed notification coverage exists.

Notification checks a processed-event ledger by EventId and has a configurable staleness policy. It records message/delivery audit and per-attempt state. Infrastructure failures requeue the broker delivery; delivery-provider failures follow a bounded retry policy and can remain failed for later Notification-owned handling.

An outbox event guarantees neither intent creation nor delivered communication. Missing recipient address, disabled preference, missing template, stale event, delivery failure, or delayed consumer can all prevent immediate delivery.

Source References​

  • microservices/src/notification-service/Application/EventNotificationResolver.cs
  • microservices/src/notification-service/Messaging/NotificationEventConsumer.cs
  • microservices/src/notification-service/Application/NotificationDispatcher.cs
  • microservices/src/notification-service/Seed/DefaultTemplateSeeder.cs
  • microservices/src/contracts/Events/LeaveLifecycleEvents.cs

See Also​

Keywords​

  • Notification intent
  • LeaveApproved
  • LeaveRejected

Revision Information​

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