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