🔔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 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.submittedcreate those cards; this screen only shows the ping. See 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 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
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.
Publish the app. The form must exist on the live app.
If the form is an update form, add at least one record. Save on an empty list does not run.
Add a Notification Center screen if it is missing. Publish the app again.
Open Automation → Create your first automation: Notify someone.
Set When this happens to the form people save.
Set Who receives it to the record owner / people field, a role, or a specific email.
Set Notification channel to In-app Notification Center, or In-app and email.
Click Run live test. Confirm a card appears under Notifications.
Publish the workflow and the app.
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
Confirm Notification Center is on the live app and Messaging live publish is enabled (Intra or higher).
Open Automation → Messaging → Announcements.
Enter a title and message. Set severity if needed.
Click Publish broadcast. Leave the announcement active.
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. Named topics that create Decision or Work Queue cards (not this inbox): Topics that perform work. First-win wizard: Start from a wizard.
Required Foundations
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
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.
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
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 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
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. Messaging and Notifications. Conversation screen.