2.12.1 Notifications — Notification Center — Events and Alerts

The Notification Center acts as the single authoritative surface for all notifications generated across the platform. It consolidates system events, user-triggered actions, automation outputs, and operational alerts into a unified, queryable stream. Notifications are treated as first-class records with explicit state and lifecycle, rather than transient UI messages.

Notification Model

Each notification represents a discrete event addressed to one or more recipients. Notifications are immutable once created and reference the originating entity or action for traceability.

Core attributes include:

Recipient scope (user, role, group)

Event type and category

Read and acknowledgment state

Timestamp and source reference

Example notification creation:

Notification::create([ 'recipient_id' => $user->id, 'type' => 'content.published', 'payload' => $data, ]);

Aggregation and Categorization

Notifications are aggregated into the Notification Center regardless of their delivery mechanism. Categorization allows users to distinguish between informational messages, warnings, and critical alerts.

Common categories:

Informational

Action required

System warning

System critical

Aggregation ensures that no notification is lost even if real-time delivery fails.

Read State and Acknowledgment

Each notification maintains an explicit read state per recipient. Reading a notification updates its visibility state without altering the underlying record. Certain notifications may additionally require acknowledgment to confirm user awareness.

Read state behavior:

Unread by default

Read when explicitly opened or marked

Acknowledged when required by policy

Ordering and Visibility

Notifications are ordered by event time, not by delivery time, ensuring consistent chronology across devices and sessions. Visibility rules prevent dismissed or acknowledged notifications from resurfacing unless the underlying event changes.

Filtering and sorting are applied at query time to support different operational views.

Persistence and Retention

Notifications persist according to tenant-defined retention policies. Expiration removes notifications from active views without retroactively altering historical audit records.

Retention guarantees:

Deterministic expiration

No silent deletion

Auditable lifecycle

Cross-Module Integration

Any module may emit notifications through a standardized interface. The Notification Center does not embed business logic; it consumes events emitted by other systems.

Example emission:

event(new NotificationEvent( recipient: $user, type: 'survey.completed', payload: $context ));

Security and Isolation

Notifications are tenant- and organization-scoped. A recipient can only access notifications explicitly addressed to them. Payloads are sanitized to prevent data leakage across scopes.

Access checks are enforced on every retrieval operation.