Notification Business Rules
Summary
This reference defines 25 source-backed rules across event intake, recipient and preference decisions, template selection, delivery, retry, inbox access and legacy administration.
Audience
Product owners, administrators, developers, QA, support, security reviewers and implementation partners.
Business Purpose
Provide the authoritative catalog for notification acceptance testing, operational interpretation and product decisions. Where legacy and extracted implementations differ, the catalog identifies the scope.
Actors
Product owners, administrators, developers, QA, support, security reviewers and implementation partners.
Business Flow
Rules follow the event from intake through resolution, suppression, rendering, persistence, delivery, retry, audit and employee read state.
Responsibilities
Product owns intent; engineering maintains source alignment; QA validates triggers and outcomes; operations applies the rules during investigation; security validates tenant and access assumptions.
Business Rules
Reference Content
| Rule | Trigger | Outcome | Validation | Source |
|---|---|---|---|---|
| NTF-BR-001 Supported-event gate | An event reaches the extracted consumer | Only one of 42 mapped event types enters dispatch | Publish mapped and unmapped event fixtures | EventNotificationResolver.cs; NotificationEventConsumer.cs |
| NTF-BR-002 Event idempotency | An event identifier was already processed | The duplicate is audited and no new message is created | Replay the same event identifier | NotificationDispatcher.cs |
| NTF-BR-003 Stale-event handling | Event age exceeds configured allowance | The event is audited as stale and recorded processed | Dispatch an event outside the configured window | NotificationDispatcher.cs; NotificationOptions.cs |
| NTF-BR-004 No-intent outcome | Resolver returns no recipients/intents | Processing records a no-recipient outcome | Use payload without a resolvable audience | NotificationDispatcher.cs |
| NTF-BR-005 Recipient identity | A resolved intent is accepted | Recipient is upserted by tenant, recipient type and external reference | Repeat intent with changed contact data | NotificationDispatcher.cs; NotificationDbContext.cs |
| NTF-BR-006 Channel de-duplication | Intent contains repeated channel names | Each normalized channel is evaluated once | Supply repeated/mixed-case channels | NotificationDispatcher.cs |
| NTF-BR-007 Preference precedence | Event-specific and wildcard preferences both exist | Event-specific setting wins | Configure conflicting scopes | PreferenceEvaluator.cs |
| NTF-BR-008 Default preference | No applicable preference exists | Channel is enabled | Remove both preference scopes | PreferenceEvaluator.cs |
| NTF-BR-009 Disabled channel | Applicable preference disables a channel | Channel is suppressed and audited | Disable the event/channel combination | NotificationDispatcher.cs |
| NTF-BR-010 Channel address | Enabled channel has no usable address | That channel is skipped and audited | Remove email or phone as applicable | NotificationDispatcher.cs |
| NTF-BR-011 Tenant template priority | Active tenant and global templates exist | Highest active tenant version is selected | Create both scopes and render | TemplateEngine.cs |
| NTF-BR-012 Global fallback | No active tenant template exists | Highest active global version is selected | Deactivate tenant versions | TemplateEngine.cs |
| NTF-BR-013 Missing template | No active tenant or global template exists | Channel is skipped and audited as template missing | Deactivate all matching versions | NotificationDispatcher.cs; TemplateEngine.cs |
| NTF-BR-014 Variable substitution | Template contains known variables | Variables are replaced from resolved data | Render representative event data | TemplateEngine.cs |
| NTF-BR-015 Missing variable | Template variable is absent from data | Placeholder becomes empty text | Render with one variable omitted | TemplateEngine.cs |
| NTF-BR-016 Persist before send | Address and template resolve | Pending rendered message is stored before delivery starts | Observe message before sender result | NotificationDispatcher.cs |
| NTF-BR-017 Bounded automatic retry | Sender reports failure | Delivery retries with configurable exponential delay until success or limit | Use deterministic failing sender | RetryPolicy.cs; NotificationDispatcher.cs |
| NTF-BR-018 Attempt evidence | A delivery try occurs | One success, failure or skipped attempt is appended | Compare attempt count with tries | NotificationDispatcher.cs |
| NTF-BR-019 Successful send | Sender succeeds | Message becomes sent with sent time and success audit | Use successful sender | NotificationDispatcher.cs |
| NTF-BR-020 Exhausted send | All allowed attempts fail or sender is absent | Message becomes failed with error and failure audit | Use failing or unregistered sender | NotificationDispatcher.cs |
| NTF-BR-021 Manual retry | Operator retries a failed message | Status returns to pending, prior error clears and delivery reruns | Retry a known failed message | NotificationDispatcher.cs; NotificationEndpoints.cs |
| NTF-BR-022 Event processed semantics | At least one message record was created | Event outcome is processed even if created messages failed | Fail every sender after message creation | NotificationDispatcher.cs |
| NTF-BR-023 Extracted template version | A service template is created for a known key/channel | Next version is assigned within tenant/key/channel scope | Create two versions and compare | NotificationEndpoints.cs; NotificationDbContext.cs |
| NTF-BR-024 Authenticated legacy inbox | Signed-in active user lists or updates notifications | Only that user's current and legacy records are read or changed | Test with two user identities | NotificationsController.cs |
| NTF-BR-025 Legacy template access and reset | Admin lists, saves, previews or resets an event-key template | Only super-admin or tenant-admin with tenant context is allowed; reset restores inherited/default behavior by scope | Exercise roles and both reset scopes | NotificationTemplatesController.cs |
Integrations
The rules cover the event consumer, resolver, recipient directory, preference evaluator, template engine, message and attempt stores, senders, legacy inbox and legacy template editor.
Limitations
The catalog describes reviewed code, not confirmed production configuration. It does not convert simulated channel success into external delivery assurance or resolve the dual template models.
Requires Confirmation
Confirm business approval for stale-event policy, mandatory notifications, retry limits, content governance, external-delivery semantics and access controls before promoting these rules beyond Draft.
Source References
microservices/src/notification-service/Application/NotificationDispatcher.csmicroservices/src/notification-service/Application/EventNotificationResolver.csmicroservices/src/notification-service/Application/PreferenceEvaluator.csmicroservices/src/notification-service/Application/TemplateEngine.csControllers/NotificationsController.csControllers/NotificationTemplatesController.cs
Related Articles
See Also
Keywords
Business rule, trigger, outcome, validation, source.
Revision Information
Draft authoritative catalog of 25 rules; reviewed 2026-07-21; next quarterly review 2026-10-21.