Notifications

Notifications are a per-user inbox. The CMS raises them when something happens that a user should know about, so reviewers and editors keep up without polling.

What triggers a notification

The CMS notifies users on:

• Mentions: being @-mentioned in a comment.
• Comments: new messages and resolved threads on a thread you are part of.
• Approvals: an approval requested from you, or your request being approved or rejected.
• Merge requests: opened, merged, closed, or reopened.
• Publishing: content published.

Each notification carries a type, a title and body, the resourceType and resourceId it points at, and a readAt (null while unread).

Delivery

Notifications are written after the triggering action commits, fire-and-forget: a notification failure never rolls back the action. Read them with listNotifications (which also returns an unreadCount), and mark them read, unread, or archived.

With realtime configured, notifications are also pushed to each recipient the moment they're raised — the useNotifications hook (under a RealtimeProvider) prepends them live on top of the poll. Without realtime, listNotifications is the only path; there is no built-in polling hook.

You can disable the feature entirely with notifications: false on createCMS — the tables, routes, and client.notifications / cms.notify types all disappear. See configuration.