For the complete documentation index, see llms.txt. This page is also available as Markdown.

🔔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

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 explains how to use each one.

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.

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.

  • Transient toast-only messages with no history.

What Users See In The Live App

  • Notification list with unread/read state.

  • Acknowledge and Dismiss actions.

  • Category-filtered notices based on app audience prefs.

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.

Required Foundations

Requirement
Why it matters

Automation screen entitlement

Notification Center appears in the Automation / Operational group.

Messaging, optional Workflow

Primary foundation for this screen’s runtime state.

Private app + Users database (recommended)

Role/tenant visibility and audience policy need user fields.

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

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 the screen to one messaging channel. How to use it: Match the exact channel used by the routes that publish notices. Why / recommended default: A channel mismatch is a common reason a notice center looks empty even though messages are being sent.

Topic

What it does: Filters the selected channel to one topic. How to use it: Use stable topic names when one channel carries several notice types. Why / recommended default: Topic filtering is useful, but it should be used on purpose. Over-filtering can hide notices people expect to see.

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

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.

This panel helps you discover the forms, workflows, and messaging objects that shape the notice experience.

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

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

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

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

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

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.

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 + Publish announcement from Automation Launcher.

Process alerts

Specific workflow notices with Acknowledge only.

Testing Checklist

Troubleshooting

User sees no notices

Category prefs opt them out, visibility hides the screen, or messaging route did not target them.

Too many notices

Listen scope is Entire app — narrow scope or tighten categories.

Best Practices

  • Configure Notification Center for one clear user job.

  • Prefer the narrowest listen scope that still shows the right work.

  • Keep payload visibility conservative for broad audiences.

  • Test as an allowed user and a blocked user before publish.

  • Pair related screens (Decision + Conversation + Workflow Status + Notification Center) instead of overloading one screen.