The Notification Center provides unified, multi-channel notification dispatch across the entire suite. A single call from any module resolves to delivery on one or more channels: the in-app inbox surfaced through the notification bell in the navigation bar, branded HTML email, mobile push and SMS. Channel selection is not hard-coded by the calling module; it is decided centrally, so the same underlying event can reach one recipient as a quiet inbox entry and another as an SMS, according to policy and preference.

Delivery is resilient by design. Each notification is dispatched per channel with independent success tracking, so a failure on one transport, a bounced email or an unreachable push endpoint, never blocks delivery on the others, and every attempt is recorded. Recipients receive a coherent experience regardless of source: a consistent inbox with unread counts, read and dismissed state, categorised grouping and deep links straight to the record that raised the alert. Digests roll up lower-priority items into scheduled email summaries, so people who prefer a periodic briefing to a stream of individual messages still stay informed without being interrupted. Severity is a first-class attribute throughout, with information, success, warning and error each carrying its own visual treatment and colour coding across every channel.

At the heart of the Notification Center are three ideas that together turn a raw system event into a message someone reads. The first is the event: a named thing that happened somewhere in the suite, such as a ticket being reassigned or an invoice falling overdue, carrying with it a payload of the facts that matter about that occurrence. Events are expressed in a simple dotted naming convention that lets whole families of them be addressed at once.

The second is the rule, which is the organisation's standing policy for a class of events. A rule listens for a pattern of events, names the audience that should hear about them, chooses the channels, sets a severity and a category for grouping, and supplies the wording. Because rules match against patterns rather than single event names, one rule can govern an entire module's activity while another targets a single precise occurrence, and administrators layer them to express exactly the coverage they want.

The third is the notification itself: the concrete, personalised message delivered to one recipient, with its own read and dismissed state and its own link back to the originating record. Audience is resolved relationally rather than by fixed lists, so a rule can address the person who triggered the event, the owner of the affected record, everyone holding a given role, or a named individual, and the correct recipients are computed fresh each time the event fires. Wording is produced from templates in which placeholders are filled from the event payload, so titles, bodies and links are specific to the instance rather than generic. Configuration of rules lives apart from the transactional records they act on, which keeps notification policy stable and centrally governed while the operational data it watches changes constantly.

The everyday workflow begins when a module emits an event. The Notification Center loads the active rules, matches them against the event by pattern, and for every rule that matches it resolves the audience, interpolates the templates against the payload and dispatches to the chosen channels. This happens in the background of ordinary operations, so a user approving a requisition or closing a ticket simply carries on while the relevant people are informed automatically.

The recipient workflow is the inbox and its companions. People triage the in-app inbox, filtering by category and severity, following deep links to act on what they see, and marking items read or dismissed; unread counts and the navigation-bar bell keep awareness current in real time. Those who prefer batched awareness receive scheduled digests instead, and time-critical severities escalate to push and SMS so nothing urgent waits for the next login.

The administrative workflow is rule management. Administrators create, edit, activate and deactivate rules from a dedicated management surface, define the event patterns and audiences, compose the templates, and toggle rules on or off without touching any module's code. A single active-state switch lets a noisy rule be silenced instantly or a new policy be staged and enabled when ready, giving the organisation direct, self-service control over its entire notification behaviour.

The precision of the Notification Center lives in its routing and templating. Pattern matching uses dotted event names with wildcard segments, so a rule can subscribe to every event a module produces, to every event of a given kind across modules, or to one exact occurrence, and the matching is deterministic and inspectable. This gives administrators fine control over breadth: broad situational awareness where it helps, surgical targeting where noise must be avoided.

Audience resolution is equally deliberate. Because recipients are derived from the event and the current state of the organisation rather than from static distribution lists, notifications always reach the right people even as ownership, roles and team membership change, and there are no stale lists to maintain. Template interpolation binds message wording to the payload, pulling named values into titles, bodies and navigation links so every message is concrete and actionable, with a working link to the exact record in question. Severity classification drives consistent treatment end to end, colour, prominence and channel escalation, so the visual language of urgency is uniform across inbox, email, push and SMS. Email itself is rendered through a branded, severity-aware template with a company-styled header, and delivery is mode-aware so messages behave correctly across development, certification and production environments. Per-channel delivery tracking and independent failure isolation mean the organisation can see what was sent, to whom, on which channel and with what outcome, which underpins both operational trust and auditability.

The Notification Center is deliberately cross-cutting: it is the channel every other module reaches for when it needs to tell someone something, which means it integrates with all of them rather than a select few. Its tightest coupling is with the Flow Engine, where a dedicated notification node lets any automated process step raise an in-app message and an email as part of a workflow, so approvals, escalations and handoffs announce themselves as they move. It sits alongside the platform event bus, so the same operational event that advances a workflow can simultaneously drive rule-based notifications, keeping process automation and human awareness in lockstep.

Concretely, service tickets from the Service Desk raise assignment and breach alerts, the Finance and Billing modules surface overdue invoices and completed payment runs, Procurement and Inventory escalate approval requests and stock exceptions, and HR and Identity changes notify the affected owners and roles. Access is governed through the suite's central permissions model, so who may author and administer notification rules is controlled under the same policy framework that protects every other system function. Because delivery, branding and read tracking are solved once here, every module inherits a professional, consistent communication experience without reimplementing any of it.

AI Workers are first-class participants in the Notification Center, not passive recipients. Staff query their notification history conversationally, asking an AI Worker to summarise what they missed, to surface only the warnings and errors from a given module, or to explain why a particular alert reached them, and the Worker reads the inbox and the governing rules to answer in plain language. Workers also act: they mark items handled, route a message onward to the right owner, or draft and dispatch a notification on a person's behalf through the same unified dispatcher, subject to the same permissions.

Because every operational signal passes through this centre, AI Workers use it as a vantage point for anomaly and exception detection: they watch the stream for unusual patterns, a sudden cluster of error-severity events, a rule firing far more than usual, an approval that has sat unread past its deadline, and raise a considered alert rather than another raw one. They extract structured detail from the events and documents behind a notification, so an alert about an overdue invoice arrives already summarised with the figures that matter. In decision support, a Worker recommends which rules to tune when a category grows noisy, and proposes audiences and severities for new policies. Most consequentially, an AI Worker serves as an approval or review node inside workflows: the Flow Engine notifies the Worker, the Worker evaluates the case against policy, and it approves, rejects or escalates, recording its reasoning and passing the decision back into the process, so the Notification Center becomes both how work is announced and, where appropriate, how it is judged.