🔔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.
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 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
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
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
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
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
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
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
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
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
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.