> 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/screens-and-components/types-of-screens/native-automation-and-operational-screen-guides/notification-center-screen.md). # Notification Center Screen > Current state: this native screen is part of **Automation**. 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 is a persistent place for announcements, alerts, unread notices, and acknowledgements. Think of this screen as **A durable inbox for notices — not a chat thread and not a work queue.** ![Builder view of this screen with the configuration panel open](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2F1CrUaLEcJ80Y1sHezY4K%2F00-builder-hero.jpg?alt=media) ## Who This Guide Is For This guide is for makers configuring a **Notification Center** screen in the app builder. It lists every builder option available on the screen, and it tells you **how to put cards on the screen**. Adding the screen is not enough. Use this guide when: * Users need lasting alerts or announcements. * Acknowledgements or dismissals should be recorded. * Category preferences should gate which notices a user receives. * The live screen is empty and you need the working populate path. ## What The Screen Is For ### Use Notification Center when * Users need lasting alerts or announcements. * Acknowledgements or dismissals should be recorded. * Category preferences should gate which notices a user receives. ### Do not use it when * Threaded discussion — use Conversation. * Claimable work — use Work Queue. Named topics such as `client.intake.submitted` create those cards; this screen only shows the ping. See [Topics that perform work](https://docs.notionapps.com/automation/messaging-and-notifications#topics-that-perform-work). * Transient toast-only messages with no history. * You only created a Messaging channel and pointed this screen at it as a subscriber. That does not fill this inbox. ## What Users See In The Live App The live screen has **two separate lists**. They are filled by two different jobs. * **Announcements** — title, message, and severity from a published broadcast. * **Notifications** — cards with Acknowledge and Dismiss, created by a workflow **Send notification** step with channel **in\_app**. * Category-filtered notices based on app audience prefs, when you configured categories. | Default | Value | | ------------------------------- | --------------------------------------------------- | | Default listen scope | Entire app | | Require claim before action | Off | | Default preview persona / state | Operator / Live | | Empty title | No notifications | | Empty description | Announcements and routed notifications appear here. | Adding Notification Center, creating a channel named `notification` or `notifications`, and attaching this screen as a subscriber **does not put a card in either list**. ## How this screen gets populated Do **not** start in Messaging Foundation and build Channel → Contract → Publisher → Subscriber. That route looks finished and then does nothing here. ### What fills each list | Live section | What actually fills it | What does not fill it | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Announcements** | Messaging → **Announcements** → title and message → **Publish broadcast**. Leave the announcement **active**. | A custom channel. A paused announcement. A form Save. | | **Notifications** | Automation Home → **Create your first automation: Notify someone**, or a workflow **Form submitted** → **Send notification** with channel **in\_app**. Then publish the workflow and the app. | A Messaging channel, contract, publisher, or this screen as a subscriber. Email-only notify. Form Save by itself. | Users must be **signed in** on the **live** app. Builder preview sample data is not a live notice. ### Populate Notifications after a form Save This is the path makers should use when they want the inbox to update after someone hits Save. 1. Publish the app. The form must exist on the live app. 2. If the form is an **update** form, add at least one record. Save on an empty list does not run. 3. Add a **Notification Center** screen if it is missing. Publish the app again. 4. Open **Automation** → **Create your first automation: Notify someone**. 5. Set **When this happens** to the form people save. 6. Set **Who receives it** to the record owner / people field, a role, or a specific email. 7. Set **Notification channel** to **In-app Notification Center**, or **In-app and email**. 8. Click **Run live test**. Confirm a card appears under **Notifications**. 9. Publish the workflow and the app. 10. On the live app, signed in as the recipient, submit the form. Open Notification Center. Refresh if needed — the screen polls about every 30 seconds. Leave Messaging channels, contracts, publishers, and subscribers alone for this job. ### Populate Announcements for everyone 1. Confirm Notification Center is on the live app and Messaging live publish is enabled (Intra or higher). 2. Open **Automation** → **Messaging** → **Announcements**. 3. Enter a title and message. Set severity if needed. 4. Click **Publish broadcast**. Leave the announcement **active**. 5. Open the live app signed in. The item appears under **Announcements**. Do not create a `notifications` channel for a broadcast. ### Why a channel subscription stays empty A Messaging **EVENT** from a form or button publisher is not a Notification Center card. This screen reads: * active **announcements**, and * automation items of type **notification**. Only a workflow **Send notification** step with channel **in\_app** creates those items. Email-only or webhook-only notify does not. Form Save can try to publish to a channel, but if the contract requires a `message` field the form never sends, publish fails silently and the Notion row still saves. If you already built Channel → Contract → Publisher → this screen as subscriber, do not keep testing Save. Use **Notify someone** above, or add a **Send notification** / **in\_app** step to a form-submitted workflow. Full Messaging reference: [Messaging and Notifications](https://docs.notionapps.com/automation/messaging-and-notifications). Named topics that create Decision or Work Queue cards (not this inbox): [Topics that perform work](https://docs.notionapps.com/automation/messaging-and-notifications#topics-that-perform-work). First-win wizard: [Start from a wizard](https://docs.notionapps.com/automation/start-from-a-wizard). ## Required Foundations | Requirement | Why it matters | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------- | | Automation screen entitlement | Notification Center appears in the Automation / Operational group. | | Messaging | Required for **Announcements** (broadcast). Intra live publish must be on. | | Workflow | Required for the **Notifications** list. Use **Notify someone** or a **Send notification** / **in\_app** step. | | Private app + Users database (recommended) | Role/tenant visibility, assignment, and audience policy need signed-in users. | ## Complete Builder Options Reference The sections below follow the builder order. Every option is explained in prose so makers can configure a durable notice center with the right audience, the right categories, and the right read/clear behavior. ### Header and screen type This section defines the notice inbox at a glance. Notification Center works best when users can tell immediately that it is for durable alerts and announcements, not chat and not claimable work. #### Screen type **What it does:** Sets the native behavior to **Notification Center**, which renders persistent notices tied to automation and messaging runtime state.\ **How to use it:** Keep the type as Notification Center. Use Conversation for threaded back-and-forth and Work Queue for claimable tasks.\ **Why / recommended default:** Each screen family has a distinct job. Mixing them together makes the notice center harder to trust. #### Category **What it does:** Places the screen in the native Automation or Operational grouping.\ **How to use it:** Keep the default grouping and place the screen where users expect to look for durable alerts.\ **Why / recommended default:** Clear structure helps makers keep notice surfaces separate from action surfaces. #### Title **What it does:** Sets the live title shown in navigation and at the top of the screen.\ **How to use it:** Use clear labels like `Notifications`, `Alerts`, or `Company notices` depending on the audience.\ **Why / recommended default:** Familiar naming helps users discover the screen naturally without training. #### Description **What it does:** Adds helper text beneath the title.\ **How to use it:** Explain what kind of notices appear here and what users should do with them, such as acknowledge or dismiss.\ **Why / recommended default:** Good description text keeps the screen from being mistaken for a support inbox or conversation thread. ### Automation source ![Annotated builder screenshot: Automation source](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FnAvGbsBFSCxbge9rmQeB%2F01-section-automation-source.jpg?alt=media) This section decides which notices the center listens to. Notification Center can be broad, but it still works best when makers are intentional about scope. #### Listen scope **What it does:** Chooses the top-level runtime source for notifications.\ **How to use it:** Use **Entire app** for a global notice center. Use **Specific workflow** when the page should only show notices from one process, such as a regulated approval flow.\ **Why / recommended default:** The common default for a shared Notification Center is **Entire app**, but narrower scope is often better when the app has several unrelated automation systems. #### Source screen or form **What it does:** Binds the screen to one intake surface when that scope is selected.\ **How to use it:** Choose the screen or form that should own the resulting notices if one intake experience is the natural boundary.\ **Why / recommended default:** This is useful for targeted portals, but broad notice centers usually do not need it. #### Workflow **What it does:** Filters the screen to notices associated with one workflow.\ **How to use it:** Pick the published workflow when users only need process-specific alerts.\ **Why / recommended default:** Workflow scope helps prevent alert fatigue by keeping a notice center focused. #### Messaging channel **What it does:** Narrows listen scope when you selected Conversation or linked-app scope.\ **How to use it:** Leave this empty for a normal inbox. Do not create a `notifications` channel and bind this screen to it expecting cards to appear. Channel events do not populate this list.\ **Why / recommended default:** An empty inbox is almost never a channel-name typo. It usually means you have not run **Notify someone** or published an announcement. See [How this screen gets populated](#how-this-screen-gets-populated). #### Topic **What it does:** Further filters a selected channel.\ **How to use it:** Leave it empty unless you already have a working notify workflow or announcement and you are narrowing a busy inbox.\ **Why / recommended default:** Topic filters hide items. They do not create them. #### Conversation or correlation **What it does:** Limits the center to a specific case or correlation context.\ **How to use it:** Use this only when the notice center is meant to accompany one request or one thread.\ **Why / recommended default:** Most Notification Center screens should stay broader than a single correlation so they behave like a true inbox. #### Linked application **What it does:** Binds the notice center to a linked NotionApps application when notices are exchanged across apps.\ **How to use it:** Choose a linked app only when cross-app notices are part of the product design.\ **Why / recommended default:** Most notice centers remain local to one app, which keeps governance simpler. ### App audience and notification prefs ![Annotated builder screenshot: App audience and notification prefs](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FzjEobTLWslbsB0LrTdJ6%2F02-section-app-audience-and-notification-prefs.jpg?alt=media) This section matters more on Notification Center than on any other screen because it defines who is eligible to see notices and which notice categories they have opted into. #### Tenant mode **What it does:** Decides whether notices are isolated by tenant relation.\ **How to use it:** Use **Relation** when each client or company should only see its own notices. Use **Off** only for truly single-tenant or fully internal apps.\ **Why / recommended default:** Tenant-aware notice delivery is usually the safer default. Broadcast-style notice visibility is a common source of unintended exposure. #### Tenant field **What it does:** Selects the Users-sheet relation that defines tenant membership.\ **How to use it:** Point at the same client, company, or workspace field used elsewhere in the app.\ **Why / recommended default:** Consistent tenant modeling keeps notice visibility predictable across screens and channels. #### Role field **What it does:** Tells the platform which field stores a user's role if it is not named `Role`.\ **How to use it:** Leave it blank for the default field name or set it explicitly for a custom schema.\ **Why / recommended default:** Role-sensitive notice delivery only works if the builder is reading the right role field. #### Notification categories **What it does:** Maps category keys and labels to user preference fields so people can opt into or out of notice types.\ **How to use it:** Add only categories you really send, such as announcements, approvals, service alerts, or reminders, then map each to a real preference field on the Users sheet.\ **Why / recommended default:** This is the most important policy section on the screen. Users who opt out of a category should not see those notices even if the screen itself is visible, so sloppy category setup leads directly to confusing inbox behavior. #### Add notification category **What it does:** Adds another category row, usually with in-app and email delivery defaults.\ **How to use it:** Create a category only when you have a real sending route and a real user preference to bind it to.\ **Why / recommended default:** A small set of meaningful categories is better than a long list of theoretical ones. #### Save audience policy **What it does:** Saves tenant and category policy at the app level.\ **How to use it:** Save after every category or tenant change before testing as another persona.\ **Why / recommended default:** Unsaved audience policy is one of the easiest ways to misread a notice-visibility test. ### Template setup state This is a diagnostic section for cloned or repaired apps. #### Setup state indicator **What it does:** Reports whether the screen setup is provisioned, needs review, or has no setup report.\ **How to use it:** Treat **Needs review** as a sign to re-check the notice source bindings, especially after template remaps or channel renames.\ **Why / recommended default:** Notification screens can look healthy in the builder while still pointing at the wrong underlying routes. This indicator helps you catch that earlier. ### Related context This panel helps you discover the forms, workflows, and messaging objects that shape the notice experience. #### Related context panel **What it does:** Shows read-only discovery counts and related runtime objects.\ **How to use it:** Use it to find the Automation Launcher that publishes announcements, the workflows that emit alerts, or neighboring screens like Workflow Status and Conversation.\ **Why / recommended default:** Discovery tools make it easier to build a coherent notice experience instead of scattering alerts across unrelated pages. ### Visibility and access ![Annotated builder screenshot: Visibility and access](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FP5CBVzJu2YTCrVZ1Kd96%2F03-section-visibility-and-access.jpg?alt=media) This section controls who can open the notice center at all. That is separate from category opt-in, which decides which notices appear after a user is already allowed onto the screen. #### Visibility rules **What it does:** Applies condition-based screen visibility.\ **How to use it:** Use role, tenant, or audience conditions to define which users can open the screen.\ **Why / recommended default:** Visibility and category preferences solve different problems. A common mistake is trying to use categories instead of real screen access rules. #### Allowed role names **What it does:** Adds a direct role allow list.\ **How to use it:** Use simple role sets like `All Users`, `Staff`, or `Admin` depending on the scope of the notice center.\ **Why / recommended default:** Clear role access is easier to audit than a mix of hidden exceptions. #### Allowed users **What it does:** Grants access to specific people by email or user reference.\ **How to use it:** Use for pilots, named stakeholders, or executive-only announcement centers.\ **Why / recommended default:** Per-user access is fine for special cases, but it should not be the main access model in a production notice center. ### Display and action policy ![Annotated builder screenshot: Display and action policy](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2F6wYBykW87onwKt3gGaLq%2F04-section-display-and-action-policy.jpg?alt=media) These settings define how much notice detail is visible and how heavy or lightweight the center feels in the live app. #### Screen title override **What it does:** Refines the user-facing title.\ **How to use it:** Use wording that matches the audience, such as `My notifications` for end users or `Operations alerts` for internal teams.\ **Why / recommended default:** The title should set expectations before a user even opens the list. #### Description **What it does:** Sets the helper copy under the title.\ **How to use it:** Explain whether users should read, acknowledge, or dismiss notices here.\ **Why / recommended default:** This small bit of guidance prevents uncertainty about what the actions mean. #### Payload visibility **What it does:** Controls how much detail from the runtime payload is shown with each notice.\ **How to use it:** Use **Metadata only** for broad or customer-facing audiences, **Redacted preview** for most internal use, and **Full payload** only for trusted operator contexts.\ **Why / recommended default:** Notice centers often reach wider audiences than other automation screens, so conservative payload visibility is usually the right default. #### Density **What it does:** Chooses comfortable or compact list spacing.\ **How to use it:** Use **Comfortable** for general audiences and **Compact** for high-volume operator alert lists.\ **Why / recommended default:** Comfortable spacing makes long notice lists easier to scan for most users. #### Show timeline **What it does:** Shows related audit or workflow activity with each notice.\ **How to use it:** Turn it on when users need extra delivery or history context. Turn it off when the center should stay very simple.\ **Why / recommended default:** Many notice centers work well without a heavy timeline, but it can be useful for operational alerts. #### Require claim before action **What it does:** Exists in the shared policy section, but Notification Center does not use claim behavior in its default model.\ **How to use it:** Leave it **Off**. Notices are acknowledged or dismissed, not claimed.\ **Why / recommended default:** Claim-based ownership is not part of the standard notification experience, so turning it on usually creates confusion. ### Available actions ![Annotated builder screenshot: Available actions](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2F6RiU6vguH7StsT4sVqcs%2F05-section-available-actions.jpg?alt=media) This section controls how users clear or record notice state. The two core actions have different meanings and should both be explained clearly in maker-facing docs. #### Acknowledge **What it does:** Marks the notice as seen or acknowledged while preserving its history.\ **How to use it:** Keep Acknowledge when users should formally record that they read an alert or announcement.\ **Why / recommended default:** Acknowledge is especially useful for compliance, policy, and important service updates where "read" matters. #### Dismiss **What it does:** Removes the notice from the active list after the user decides it no longer needs attention.\ **How to use it:** Keep Dismiss when the notice center should stay tidy and users may want to clear informational items after reading them.\ **Why / recommended default:** Dismiss is helpful for reducing noise, but makers should use it carefully on notices that must remain easy to audit. #### After-action screen **What it does:** Routes the user to another screen after acknowledging or dismissing a notice.\ **How to use it:** Most makers leave users on the notice center, but you can send them to Workflow Status, Conversation, or another follow-up page when a notice naturally points somewhere specific.\ **Why / recommended default:** Staying in the notice center is the least surprising default. Redirects are best only when the next step is obvious. #### Target workflow **What it does:** Supplies a workflow target for custom actions that launch or escalate into another process.\ **How to use it:** Leave it empty for the standard Acknowledge and Dismiss actions.\ **Why / recommended default:** Unused workflow bindings add complexity without improving the notice experience. ### Preview scenario ![Annotated builder screenshot: Preview scenario](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FoARQpClXdog8gtxApmle%2F06-section-preview-scenario.jpg?alt=media) Preview settings help makers check whether the notice list stays readable across devices and whether the empty state feels intentional. #### Device and orientation **What it does:** Changes the preview frame across desktop, tablet, and mobile sizes.\ **How to use it:** Always check mobile because notices are commonly consumed on phones.\ **Why / recommended default:** A notice center that breaks on mobile will often be ignored even if the alerts themselves are important. #### Test persona **What it does:** Simulates the viewer role.\ **How to use it:** Test with the real audience, not only as Admin, especially when categories or tenant policy differ across user groups.\ **Why / recommended default:** Persona testing is critical because notification gating is often policy-driven rather than visually obvious. #### Preview state **What it does:** Simulates states such as Live, Empty, Loading, and Error.\ **How to use it:** Check **Live** for the normal list, **Empty** for calm idle behavior, and **Error** to ensure the screen still feels trustworthy under failure conditions.\ **Why / recommended default:** The default preview state is **Live**, but the empty state is often what new users see first. #### Test mode **What it does:** Switches between simulated preview and live testing.\ **How to use it:** Use live testing before publish to confirm notice routing and category gating with real personas.\ **Why / recommended default:** Simulation helps with layout, but only live testing proves the notice policy is correct. ### Empty state and sample data ![Annotated builder screenshot: Empty state and sample data](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FMAY9JxmSX8nmjJnBAtZX%2F07-section-empty-state-and-sample-data.jpg?alt=media) Quiet inboxes should feel calm, not broken. #### Empty title **What it does:** Sets the headline shown when no notices match.\ **How to use it:** Keep the default `No notifications` unless your audience uses a more specific label like `No alerts`.\ **Why / recommended default:** The default is short, familiar, and easy to understand. #### Empty description **What it does:** Explains when notices will appear.\ **How to use it:** Keep or adapt the default `Announcements and routed notifications appear here.`\ **Why / recommended default:** Simple empty copy reassures users that the center is just quiet. #### Sample item, run, or conversation **What it does:** Provides builder-only sample references for preview and screenshots.\ **How to use it:** Use representative notices from a few categories so you can validate list density, action labels, and payload visibility before publish.\ **Why / recommended default:** Good sample data helps you catch problems such as overly long titles or confusing category presentation before real users do. ## Recommended Default Setup | Setting | Recommended value | | ------------------------------------ | --------------------------------------------------------------------- | | Listen scope | Entire app for a global center; Specific workflow for process notices | | Visibility | All signed-in users or role-scoped groups | | Payload visibility | Metadata only or Redacted | | App audience notification categories | Map categories to user-sheet preference fields | | Actions | Acknowledge, Dismiss | ## Common Configuration Patterns ### Company announcements Entire app listen scope. Messaging → **Announcements** → **Publish broadcast**. Leave it active. ### Process alerts after Save Entire app or Specific workflow. Automation → **Notify someone** on that form, channel **In-app Notification Center**. Do not use a Messaging subscriber for this. ## Testing Checklist * [ ] Run **Notify someone** live test and confirm a card under **Notifications**. * [ ] Publish a broadcast and confirm it under **Announcements** (status **active**). * [ ] On the live app, signed in as the recipient, submit the form and see the card. * [ ] Acknowledge and confirm unread state clears. * [ ] Dismiss and confirm it leaves the active list. * [ ] Toggle a notification category preference and confirm gating. * [ ] Confirm a channel + this screen as subscriber does **not** count as a passing test. ## Troubleshooting ### User sees no notices Most common: the screen exists, but nothing has created an announcement or an **in\_app** notification item. What to check: * Did you use **Notify someone** or a **Send notification** / **in\_app** step? A Messaging channel + subscriber is not enough. * Is the announcement **active**, not paused? * Is the user signed in on the **live** app (not only builder preview)? * If this is an update form, did they select a row before Save? * Did category prefs opt them out, or does visibility hide the screen? * Email-only notify will not create a card here. ### Save succeeded and Notification Center still did nothing Form Save writes the Notion row first. A channel publish can fail silently (often a contract that requires `message`, which the form does not send). Even a successful channel EVENT does not become a Notification Center card. Use **Notify someone**. ### Too many notices Listen scope is Entire app — narrow to one workflow, or tighten categories. ## Best Practices * Populate the screen with **Notify someone** or **Announcements** before you edit listen scope, channels, or categories. * Do not send makers into Channel / Contract / Publisher / Subscriber for this inbox. * Prefer the narrowest listen scope that still shows the right work. * Keep payload visibility conservative for broad audiences. * Test as the recipient on the live app, not only as the maker in preview. * Pair related screens (Decision + Conversation + Workflow Status + Notification Center) instead of overloading one screen. ## Related [Start from a wizard](https://docs.notionapps.com/automation/start-from-a-wizard). [Messaging and Notifications](https://docs.notionapps.com/automation/messaging-and-notifications). [Conversation screen](https://docs.notionapps.com/screens-and-components/types-of-screens/native-automation-and-operational-screen-guides/conversation-screen).