Notification Consumed Events

Summary

The authoritative inventory. 42 event types are declared in the resolver's supported list, bound by the consumer, and mapped to a template key, a recipient audience and a default channel set. Each appears exactly once here.

Audience

Engineers, architects, QA, support, security reviewers and implementation partners.

Reference Content

The verified reference material for this topic is set out in the sections below.

Reading this inventory

• Direction is inbound for every row; Notification consumes only.
• Publisher is the owning service by family.
• Consumer is the Notification Service in every row.
• Template key is what the resolver passes for template resolution — usually the event type, but the Asset and Performance families use a dotted key.
• Channels are the resolver defaults, overridable per event type by configuration.
• Version is the envelope schema version, which is 1 by default and never branched on.
• Source is the resolver for every row.

Employee, Leave, Payroll, Document and Platform

Event	Publisher	Template key	Channels	Recipient
EmployeeCreated	Employee	EmployeeCreated	In-app, Email	The created employee
LeaveApproved	Leave	LeaveApproved	In-app, Email	The requesting employee
LeaveRejected	Leave	LeaveRejected	In-app, Email	The requesting employee
PayrollFrozen	Payroll	PayrollFrozen	In-app only	Operational recipient
PayslipGenerated	Payroll	PayslipGenerated	In-app, Email	The employee
DocumentGenerated	Document	DocumentGenerated	In-app, Email	The subject employee
TenantProvisioned	Platform	TenantProvisioned	In-app, Email	Provisioning recipient

PayrollFrozen is the only event whose default channel set is in-app only.

Expense

Event	Publisher	Template key	Channels	Recipient
ExpenseApproved	Expense	ExpenseApproved	In-app, Email	The claimant
ExpenseRejected	Expense	ExpenseRejected	In-app, Email	The claimant
ExpensePaid	Expense	ExpensePaid	In-app, Email	The claimant

Asset

All six share one payload record and one lifecycle handler, differing only by template key.

Event	Publisher	Template key	Channels
AssetRequested	Asset	Asset.Requested	In-app, Email
AssetAssigned	Asset	Asset.Assigned	In-app, Email
AssetReturned	Asset	Asset.Returned	In-app, Email
AssetRejected	Asset	Asset.Rejected	In-app, Email
AssetLostOrDamaged	Asset	Asset.LostOrDamaged	In-app, Email
AssetRetired	Asset	Asset.Retired	In-app, Email

Performance

Seven events share one payload record and one handler parameterised by template key and audience.

Event	Publisher	Template key	Audience
ReviewCycleOpened	Performance	Performance.ReviewCycleOpened	Employee
ReviewCycleClosed	Performance	Performance.ReviewCycleClosed	Employee
GoalCreated	Performance	Performance.GoalCreated	Employee
AppraisalSelfSubmitted	Performance	Performance.ManagerReviewRequired	Manager
AppraisalManagerReviewed	Performance	Performance.CalibrationRequired	HR
AppraisalApproved	Performance	Performance.AppraisalApproved	Employee
RatingFinalized	Performance	Performance.RatingFinalized	Employee

Two events deliberately re-target: a self-submission notifies the manager that a review is required, and a manager review notifies HR that calibration is required. The template key therefore describes the required action, not the source event.

Training and certification

Event	Publisher	Template key	Channels
TrainingAssigned	Training	TrainingAssigned	In-app, Email
TrainingStarted	Training	TrainingStarted	In-app, Email
TrainingCompleted	Training	TrainingCompleted	In-app, Email
AssessmentPassed	Training	AssessmentPassed	In-app, Email
AssessmentFailed	Training	AssessmentFailed	In-app, Email
CertificateIssued	Training	CertificateIssued	In-app, Email
CertificateExpiringSoon	Training	CertificateExpiringSoon	In-app, Email
TrainingSessionScheduled	Training	TrainingSessionScheduled	In-app, Email
TrainingSessionRescheduled	Training	TrainingSessionRescheduled	In-app, Email

Helpdesk

Ten events share one payload record and one handler parameterised by audience. This is the only family that can produce multiple recipients from one event.

Event	Publisher	Template key	Audience
TicketCreated	Helpdesk	TicketCreated	Requester
TicketAssigned	Helpdesk	TicketAssigned	Assignee
TicketCommentAdded	Helpdesk	TicketCommentAdded	Requester and assignee
TicketStatusChanged	Helpdesk	TicketStatusChanged	Requester
TicketResolved	Helpdesk	TicketResolved	Requester
TicketClosed	Helpdesk	TicketClosed	Requester
TicketReopened	Helpdesk	TicketReopened	Assignee or admin
TicketSlaBreached	Helpdesk	TicketSlaBreached	Admin
TicketEscalated	Helpdesk	TicketEscalated	Admin
TicketAttachmentAdded	Helpdesk	TicketAttachmentAdded	Requester and assignee

Multi-recipient audiences are de-duplicated by recipient type and external reference before intents are produced, so a ticket whose requester is also its assignee yields one notification rather than two.

Totals

Metric	Count
Supported event types	42
Queue bindings	42
Resolver cases	42
Distinct template keys used	42
Families	10
Events defaulting to in-app only	1
Families able to yield multiple recipients	1

Verified absence

No Workflow, Recruitment, Attendance, Organization, Onboarding or Identity event appears in the supported list. An event of an unsupported type that reached the queue would resolve to no intents and be recorded with a no-recipient outcome.

Classification

Implemented.

Requires confirmation

Whether the unmapped modules are intended to raise notifications requires confirmation.

Related Articles

• Handlers
• Integration events
• Broker topology

See Also

• Published events
• Compatibility

Keywords

• Notification database
• Consumed Events
• Draft database documentation

Source References

• microservices/src/notification-service/Application/EventNotificationResolver.cs
• microservices/src/notification-service/Messaging/NotificationEventConsumer.cs
• microservices/src/notification-service/Seed/DefaultTemplateSeeder.cs
• microservices/src/notification-service/Application/NotificationOptions.cs

Revision Information

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