Skip to content

Notifications

Notifications is the personal attention center for operational events that may require awareness or action.

It brings signals from different Comers domains into one place while keeping the underlying business record in the module that owns it.

flowchart TD
    B[Business activity or SmartOps] --> N[Notifications]
    N --> I[In-app notification]
    N --> M[Email notification or summary]
    N --> E[Comers Events]
    E --> W[Webhook / automation]
    W --> X[External system]

Comers can surface notifications directly in the application.

The Notifications workspace lets you review incoming items, distinguish unread from read notifications, open details, and archive items that no longer need to remain in the active view.

Where a notification is connected to a supported Comers record, the interface can provide a direct path to that record.

Not every event deserves the same level of attention.

Notifications can distinguish ordinary operational information from critical items. The top bar exposes separate attention signals so users can quickly open the full notification view or focus on critical notifications.

Critical status should be treated as prioritization, not as a replacement for the workflow in the source module.

Notifications can come from different operational domains, such as Orders, Shipping, Messages, or system activity.

The Notifications view can group or filter items by their domain so the user can understand what area of the business is generating attention.

The exact catalogue grows with the capabilities enabled in Comers.

Email notifications and SmartOps summaries

Section titled “Email notifications and SmartOps summaries”

Supported notification flows can also use email.

Email is useful when the user needs to receive important information outside the active Comers session. This includes configured SmartOps email summaries where that capability is enabled.

The Organization controls the available notification behavior through Business Settings, while effective user preferences determine which optional notifications a particular person receives.

SmartOps can enrich supported notification payloads with operational analysis.

For message-related notifications, this can include a concise SmartOps summary and a recommended action. Depending on the message type and available analysis, the notification context can also carry information such as topic, urgency, sentiment, whether action appears to be required, or a due time.

The same enrichment can be used in email templates, allowing the recipient to understand the nature of the case before opening Comers.

SmartOps enrichment supports attention and prioritization; the underlying business record remains authoritative.

See SmartOps and Messages.

Users can manage supported personal notification preferences from their profile settings.

A preference applies within the notification policy made available by the Organization. Turning a personal preference on does not create a new notification type or bypass an organization-level policy.

For the organization-level configuration, see Business Settings.

Read state answers whether a notification still needs the user’s attention.

Archiving is separate from reading. An archived notification is removed from the active notification list but remains available in the archive rather than being treated as deleted history.

The interface also supports working with multiple selected notifications when a bulk action is appropriate.

From a notification to the underlying work

Section titled “From a notification to the underlying work”

A notification should point attention to an operational fact, not duplicate the full workflow.

When a notification references a supported entity, open the related record to continue the actual work in its owning module.

For example, an order-related notification can lead back to the Order where the full operational context is available.

Supported notification activity can also be published into Comers Events.

This provides the extension path for systems outside Comers:

Notification activity → Comers Event → subscription/webhook → automation or external system

The Notifications module therefore does not need to contain a dedicated direct connector for every destination. External delivery and follow-up can use the common Events and webhook model.

Where supported, Agent Comers can use permitted notification context to help summarize or prioritize operational attention.

The same authorization rules still apply: the Agent does not gain access to records or business scopes that the current user cannot access directly.