> For the complete documentation index, see [llms.txt](https://docs.notionapps.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.notionapps.com/customize-app/types-of-screens/automation-screens/notification-center.md). # Notification Center ## Notification Center Screen > Current state: this native screen is part of **Automation (Beta Testing)**. It is entitlement-gated, uses NotionApps runtime state instead of ordinary Notion data controls, and should be tested with realistic workflow or messaging activity before a maker relies on it in production. The **Notification Center** screen gives users a durable place to read announcements, alerts, routed notices, unread items, and acknowledgement requests after transient banners or emails are gone. Think of this screen as **an in-app notification inbox backed by Messaging**. It should help the right person understand what is happening and what they can safely do next without reading raw JSON, copying internal IDs, or opening backend logs. ### Who This Guide Is For This guide is for makers configuring a **Notification Center** screen in the app builder. It explains the purpose of the screen, what users see after publication, what each builder section means, and how to avoid confusing or unsafe setups. Use this guide when: * Users need to revisit alerts or announcements. * A workflow sends persistent notices. * Makers need acknowledgement or dismissal behavior. * You need to choose between announcements, conversations, and queue work. ### What The Screen Is For Use Notification Center for messages that are primarily one-way or acknowledgement-based. The user reads, acknowledges, dismisses, or follows a separate route. It is not a chat screen and not a task ownership screen. Good examples: * A service announcement appears to all app users. * A workflow notifies a user that a request moved stages. * A team receives an alert about an overdue process. * A policy update requires acknowledgement. * An app owner posts release or maintenance notices. Bad examples: * Back-and-forth discussion. Use Conversation. * Claimable work. Use Work Queue. * Approval decisions. Use Decision. * Detailed run monitoring. Use Workflow Status. * Operational health dashboards. Use Operator Console. ### The Mental Model A **Notification Center** screen has three layers. | Layer | What it means | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | | Builder configuration | The maker chooses the source, access rules, display rules, actions, preview state, and empty copy. | | Automation runtime state | NotionApps creates or receives workflow, messaging, queue, notification, exchange, or operator state that belongs to the screen. | | Live user experience | A user opens the app, sees only the allowed state, and either reviews it, acts on it, or uses it as context. | The key idea is: ``` Notification Center is for durable notices, not discussions or work ownership. ``` ### What Users See In The Live App In the live app, Notification Center renders an **Announcements** section and a **Notifications** section. Announcements show title, message, and severity. Notification items render as cards with details and acknowledge/dismiss actions. A live **Notification Center** screen can show: * Announcement title and message. * Announcement severity. * Notification item title, status, summary, due date when available. * Safe details when payload preview is enabled. * Acknowledge button. * Dismiss button. * Empty state when no notifications exist. Notification Center is the best place for persistent information that users may need after they close an email, toast, or push notice. If the user needs to reply, add a Conversation screen and route from the notification to it. ### Required Foundations And Entitlements Notification Center requires Messaging Foundation for announcements and routed notifications. Workflow Foundation is optional when notifications are produced by workflow steps, schedules, form submissions, or webhooks. | Requirement | Why it matters | | ----------------------------- | --------------------------------------------------------- | | Automation screen entitlement | Notification Center appears in the Automation group. | | Messaging Foundation | Announcements and notifications are messaging-backed. | | Workflow Foundation, optional | Needed when workflow steps create notifications. | | User identity, recommended | Read, dismiss, and acknowledge state is usually per user. | ### Builder Configuration Sections The builder page for every native automation screen has the same major sections. The controls are shared, but the meaning changes depending on the screen type. Read the section notes below before publishing the screen, because most configuration mistakes come from choosing a broad listen scope, exposing too much payload detail, or giving the wrong users action access. #### Header And Screen Type The top of the configuration panel identifies the screen as a **Native app screen** and shows the saved screen type. This matters because native automation screens do not read Notion rows directly. They read NotionApps runtime state: workflow runs, queue items, decisions, messages, notifications, exceptions, linked app exchanges, and operator summaries. The title and description shown here are the same words users see in the live app unless the screen is using a template preview state. For **Notification Center**, the maker should name the screen for the user job, not for the internal system. Use names like **Notifications**, **Alerts**, **Announcements**, **Inbox**. Avoid names that expose implementation details such as workflow IDs, route IDs, channel names, or support references. #### Automation Source Automation source is the most important section. It decides which runtime events this screen listens to. If the source is too broad, users may see unrelated work. If it is too narrow, the screen may look empty even though automation is running. For Notification Center, source binding decides which notices belong in the inbox. Entire app is common for app-wide notifications; workflow or channel/topic scope is better for targeted alerts. | Listen scope | How to use it for Notification Center | | ------------------------------ | ------------------------------------------------- | | Entire app | Use for app-wide notifications and announcements. | | Specific screen or form | Use for notices created from one form route. | | Specific workflow | Use for notifications from one process. | | Conversation or message thread | Use for channel/topic-based alerts. | | Linked application | Use when linked app traffic produces notices. | Makers should normally start with the narrowest scope that still matches the business job. Use **Entire app** for owner dashboards and shared team inboxes. Use **Specific workflow**, **Specific screen or form**, **Conversation or message thread**, or **Linked application** when the screen belongs to one process. #### Template Setup State This section reports whether a managed template or demo provisioning run remapped this screen correctly. If the screen came from a cloned app, provisioning should connect the cloned screen to the cloned workflows, channels, topics, linked apps, and generated objects. A healthy screen usually shows **Provisioned**. **Needs review** means the app may still open, but the screen should not be trusted until the binding is checked or Automation Home repair is run. **No setup report** is normal for apps that were built manually rather than cloned from a template. For **Notification Center**, review this section after cloning a template, repairing a demo, changing a workflow, renaming a messaging channel, or replacing a form. The screen may still exist visually after those changes, but it can become pointed at old runtime objects unless provisioning remaps it. #### Related Context Related context is the builder's sanity check. It summarizes how many screens/forms, controls, workflows, and messaging channels are available to the screen picker. Hidden screens can appear here on purpose. A workflow may route a user to a hidden screen, or a native screen may listen to a hidden form that is not shown in navigation. Deleted screens should not be selected. For this screen, related context is especially useful for: * Finding channels/topics used for announcements. * Checking workflows that publish notifications. * Selecting screens to open after users acknowledge a notice. * Previewing recent messages as sample notification context. #### Visibility And Access Visibility and access uses the same visibility model as normal data screens when the app is private and has a user database. That means makers can use user-record fields such as role, team, department, email, or plan to decide who sees the screen. The advanced allow lists are tighter controls: allowed role names limits access to matching role values, and allowed users limits access to specific emails or saved user references. For operational screens, prefer explicit roles such as Admin, Supervisor, Operations, or Support instead of broad end-user access. Recommended access for **Notification Center**: * App-wide announcements can be visible to all app users. * Team alerts should be role-filtered. * Sensitive notifications should use participant visibility rules. * Admin-only system notices should be restricted to owners/operators. #### Display And Action Policy This section controls the words, density, payload exposure, timeline visibility, and claim policy. It is where a maker turns a technical automation surface into a usable live app screen. | Setting | What it means for Notification Center | Recommended default | | --------------------------- | --------------------------------------------------- | ------------------------------------------------------------ | | Screen title | Names the inbox. | Notifications or Announcements | | Description | Explains what kind of notices appear. | Read alerts and acknowledge important updates. | | Payload visibility | Controls extra data attached to notification cards. | Metadata only or redacted preview. | | Density | Controls list density. | Comfortable for normal users; compact for heavy alert feeds. | | Show timeline | Usually less important than notices themselves. | Off or optional. | | Require claim before action | Not relevant for normal notifications. | Off. | Payload visibility has three levels: | Level | Meaning | When to use it | | ---------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Metadata only | Shows status, title, timestamps, and safe runtime metadata without record details. | Use for broad audiences, customer-facing status, and screens where the payload contains private data. | | Redacted preview | Shows selected safe details and hides sensitive or technical fields. | Use for most operational and human-work screens. | | Full payload | Shows the fullest runtime payload available to the screen. | Use only for trusted internal operators or support-style screens. | #### Available Actions Available actions are the commands users can run from the live screen. Some screens are read-only. Others can claim work, complete work, submit decisions, reply to a conversation, acknowledge notifications, dismiss notices, escalate, or launch a workflow. Actions can optionally route the user to another screen afterward, and some actions can target a workflow. | Action | Runtime action type | What it does | | ----------- | -------------------------- | ------------------------------------------------------ | | Acknowledge | `notification.acknowledge` | Records that the user has seen or accepted the notice. | | Dismiss | `notification.dismiss` | Clears or hides the notice for the user. | Use acknowledge for notices that need an audit signal. Use dismiss for low-risk informational notices. Do not rely on dismiss for policy acceptance unless the workflow treats it as a formal acknowledgement. #### Preview Scenario Preview scenario is for builder validation, screenshots, and automated tests. It does not force live users into fake data. Use it to inspect desktop, tablet, and mobile layouts; portrait and landscape; requester, technician, supervisor, operator, and admin personas; and runtime states such as empty, loading, error, waiting approval, claimed by me, claimed by another user, overdue, or conversation active. For **Notification Center**, preview these states before publishing: * Live data, to inspect real announcements. * Empty, to verify no notifications copy. * Overdue, to check urgent styling. * Mobile portrait, to verify long announcement text. * Requester and admin personas, to verify targeted notices. #### Empty State And Sample Data Empty state and sample data controls what users see when no matching runtime state exists. A good empty state tells the user whether they are finished, waiting for someone else, or missing setup. Sample item, sample workflow run, and sample conversation are builder-only references used to preview a known object before production traffic exists. Good empty-state copy for **Notification Center** should answer: * Does no notifications mean the user is caught up? * Should the user expect future alerts here? * Is setup missing, or is the inbox simply quiet? ### Common Configuration Patterns Notification Center can support broad broadcasts and narrow workflow alerts; the source and access rules distinguish them. #### App-Wide Announcements All signed-in users can read durable notices. Recommended configuration: * Listen scope: Entire app. * Visibility: all app users or broad allowed roles. * Payload visibility: metadata only. * Actions: acknowledge or dismiss depending on notice type. #### Workflow Alert Inbox A workflow sends targeted alerts to a role or user. Recommended configuration: * Listen scope: Specific workflow or channel/topic. * Visibility: target role/user. * Payload visibility: redacted preview. * Timeline: optional. #### Policy Acknowledgement A user must acknowledge an important update. Recommended configuration: * Action: Acknowledge. * Visibility: affected users. * Workflow: records acknowledgement if formal tracking is needed. * Empty copy: no policies need acknowledgement. ### Testing Checklist Before publishing or handing this screen to a customer, test the following. * [ ] Publish an announcement and verify it appears. * [ ] Create a workflow notification and verify the correct user sees it. * [ ] Acknowledge a notice and confirm state changes. * [ ] Dismiss a notice and confirm it clears as expected. * [ ] Verify unrelated users do not see targeted notices. * [ ] Test long announcement messages on mobile. * [ ] Confirm empty state after notices are handled. ### Troubleshooting #### Announcement appears but notification item does not What it usually means: The announcement and item may come from different runtime collections or source scopes. What to check: * Check channel/topic. * Check workflow item creation. * Check source binding. * Review messaging dashboard. #### Users cannot acknowledge What it usually means: Action handling may be blocked by identity or entitlement. What to check: * Confirm user is authenticated. * Check Messaging entitlement. * Check action status/error. * Refresh runtime state. #### Too many notices appear What it usually means: Entire app scope is too broad. What to check: * Narrow to workflow or channel/topic. * Add role visibility. * Separate announcements from targeted alerts. ### Best Practices * Use concise notification titles. * Use acknowledge only when it means something. * Use Conversation for replies. * Keep payload conservative. * Separate urgent operational alerts from general announcements. * Test read/ack/dismiss state as real users. ### Recommended Default Setup Use this as a safe first configuration when the maker is unsure. * Listen scope: Entire app for announcements or Specific workflow for alerts. * Visibility: all users for public notices, role rules for team alerts. * Payload visibility: Metadata only. * Show timeline: off unless operators need it. * Require claim before action: off. * Preview state: live and empty.