Email is noisy. Chat is fragmented. An in-app notification centre is where users see things that matter in the context of the application itself, without having to switch windows, search through an inbox, or wonder whether the message ever arrived. The notifications that come from the platform live inside the platform — which means every notification can carry a direct link to the exact record, page, or action that triggered it, and every "mark as read" is an unambiguous signal that the recipient has actually seen the thing.
The in-app inbox is visible from anywhere in the application. A badge in the top bar shows the unread count; a dropdown surfaces the most recent entries with a single click. Each notification carries a short title, a more detailed message, and a link — the link is the point, because it takes the user directly to the relevant place without them having to navigate the application to find it. Your order #4521 was approved opens the order. Task "quarterly review" was assigned to you opens the task. The nightly import finished with 3 warnings opens the warnings. No hunting.
Read and unread state is handled both automatically and manually. Opening a notification marks it read. Users can also toggle state by hand — useful when something has been glanced at but deserves a follow-up later. An archive keeps older notifications out of the active list without deleting them; users can search the archive when they need to track down something historical, so "when did that import finish last month?" has an easy answer.
Pagination and archive search matter for busy inboxes. A user who is mentioned frequently or whose name gets attached to a lot of automated follow-ups won't be fighting an infinite scroll — the inbox handles thousands of entries gracefully, and the archive gives a searchable long-term record.
Sending a notification from an automation is a one-step action in the builder. Pick the recipient (or recipients — a notification can address a single user, a role, or the output of a query), write the title and body using the inline expression language so the message can include record-specific details, and optionally set a link target. A sales pipeline automation might send "New high-value deal assigned to you — $45,000" to the account owner, linked to the deal itself, the moment the deal is created. A support workflow might notify a supervisor whenever a ticket has been open too long. The automation article covers the builder in detail; from the notification side, the relevant point is that notifications are a first-class action the builder exposes natively.
A parallel system notification action covers the cases where notifications come from system contexts rather than user-driven automations — scheduled jobs, external triggers, long-running imports. The semantics are the same; the authoring path is slightly different because the acting "user" isn't a person.
Mentions drive notifications automatically, which closes the loop with the comments and rich-text features. When a colleague @-mentions a user anywhere rich text is supported — a comment on a record, a description field, a canvas block — the mentioned user gets a notification with a link straight to the spot their name was dropped. That's the difference between "tell someone and hope they notice" and "tell someone and know they've been pinged."
Custom recipient identifiers are a small feature that matters for integrations. When an external system generates a notification — your CRM, your ticketing system, your payroll — it often knows the recipient by an external identifier rather than by the platform's internal user ID. The notification API accepts custom recipient identifiers, and the platform resolves them to the right user account. Partner integrations don't have to maintain a second identity map.
The notification API exposes fetch, mark-read, and archive operations as REST endpoints. That matters for two reasons. First, mobile and external clients can build their own notification UI against the same data — so a companion mobile app, a desktop helper, or a partner portal can surface notifications without needing a second notification system. Second, automated bots and integrations can act on notifications programmatically. The authoritative state lives in the platform; anything that wants to read or update it speaks the same API.
Localization applies to notification strings, which is the quietly-important detail for international tenants. A mention from a user writing in German lands in the recipient's inbox with the system portions of the notification in whatever language the recipient has selected. The authored part of the message comes through unchanged; the platform's framing ("you were mentioned in...") adapts automatically.
Combined with real-time delivery, notifications arrive live. When an event generates a notification, the recipient's badge and dropdown update within a fraction of a second, with no refresh required. A user working in another tab sees the badge change the moment the event happens. That latency is what separates a real in-app notification system from one that just looks like one — and it's what makes the in-app inbox a legitimate substitute for the constant email interruptions that most teams would rather leave behind.
The mentions-and-comments article, the automations article, and the real-time-delivery article are all natural companions to this one. Together they form the collaboration layer — the part of the platform that makes it feel less like an application and more like a shared workplace.