💬Conversation
Conversation 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 Conversation screen displays workflow-aware and messaging-backed conversations inside the live app. It supports contextual threads, direct chats with authenticated app users, replies tied to workflow or record context, and message history.
Think of this screen as a private business conversation tied to app context. 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 Conversation 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 ask questions or reply inside the app.
A workflow waits for clarification.
A support or review process needs a durable message thread.
A maker needs to decide between Conversation, Notification Center, and Work Queue.
What The Screen Is For
Use Conversation when the main job is back-and-forth communication. It can be tied to a record, workflow run, conversation ID, correlation ID, channel, topic, or direct chat between authenticated users.
Good examples:
A requester and reviewer discuss missing information.
A supervisor asks an employee for clarification.
A support user replies to a customer inside the app.
A workflow posts status updates and allows replies.
Two linked apps exchange a request conversation.
Bad examples:
A broad announcement that users acknowledge. Use Notification Center.
A single approval outcome. Use Decision.
A task inbox. Use Work Queue.
A workflow health dashboard. Use Operator Console or Workflow Status.
A public unauthenticated comment wall. Conversation expects identity and privacy rules.
The Mental Model
A Conversation 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, users can see conversation guidance, a New chat panel, contact search, conversation switcher, grouped chats, message history, and a reply composer when a specific thread is selected.
A live Conversation screen can show:
New chat control for authenticated app users.
Searchable people list for direct conversations.
Conversation groups such as people and work-related threads.
Conversation cards with title, preview, status, metadata, and last updated time.
Message bubbles with sender labels and timestamps.
Reply composer for selected conversations.
Start-chat prompt when no thread is selected.
Empty state when no messages exist.
Conversation uses channel, topic, conversation ID, and correlation ID to keep replies attached to the right thread. The live screen should hide raw references from users unless support details are intentionally exposed elsewhere.
Required Foundations And Entitlements
Conversation requires Messaging Foundation. Reply and new-chat behavior require live message publishing permission. Workflow Foundation is optional but powerful when messages need to start, pause, resume, or update workflow state.
Automation screen entitlement
Conversation appears in the Automation group.
Messaging Foundation
Messages, channels, topics, conversations, and replies come from Messaging.
Messaging live publish
Users cannot send replies or start chats without publish capability.
Authenticated users/private app, recommended
Direct chat and participant privacy depend on known users.
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 Conversation, the maker should name the screen for the user job, not for the internal system. Use names like Messages, Request Conversation, Support Chat, Review Discussion. 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 Conversation, the source controls which message stream the screen loads and where replies go. The default for Conversation is conversation-focused because broad message streams can be noisy.
Entire app
Use rarely, for owner review of many conversations.
Specific screen or form
Use when messages belong to submissions from one form.
Specific workflow
Use when a workflow owns the discussion context.
Conversation or message thread
Best default for a focused chat using channel/topic/conversation/correlation.
Linked application
Use when messages are exchanged with another app.
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 Conversation, 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 and topics used by existing routes.
Selecting recent conversation or correlation references for preview.
Confirming authenticated users can be selected for direct chat.
Checking generated recipes that created messaging objects.
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 Conversation:
Only participants, assigned users, or relevant roles should see private conversations.
Use user database restrictions for requester/reviewer conversations.
Use Admin/Support access for broad conversation monitoring.
Do not expose cross-customer conversations through Entire app scope.
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 conversation surface.
Messages or Request Conversation
Description
Explains what users should discuss here.
Ask questions and reply in context.
Payload visibility
Usually less important than message body, but controls attached details.
Redacted preview.
Density
Controls spacing in conversation cards and message lists.
Comfortable.
Show timeline
Can show related workflow/message events when available.
Optional; often off for simple chat.
Require claim before action
Not usually needed for normal chat.
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.
Send reply
conversation.reply
Publishes a reply to the selected conversation or correlation.
Start new chat
conversation.start
Creates a direct conversation with a selected authenticated user.
Make sure channel and topic defaults are safe before enabling live replies. If a conversation should affect workflow state, configure the receiving workflow or messaging subscriber separately.
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 Conversation, preview these states before publishing:
Conversation active, to verify threaded replies.
Empty, to verify no-message copy.
Loading and error states, to verify messaging setup guidance.
Mobile portrait, to validate message bubbles and composer.
Requester and supervisor personas, to verify participant privacy.
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 Conversation should answer:
Should the user start a chat, select an existing thread, or wait for a workflow message?
Is the missing conversation due to setup or because nobody has spoken yet?
Does the empty copy avoid mentioning internal messaging terms?
Common Configuration Patterns
Conversation screens should be designed around who is talking and what object they are talking about.
Record Clarification Thread
A workflow asks a user for missing information about one record.
Recommended configuration:
Listen scope: Conversation or message thread.
Channel/topic: the route used by the workflow.
Conversation/correlation: record ID or workflow run ID.
Visibility: requester and reviewer roles.
Messaging live publish: required.
Support Chat
A support team talks with an app user.
Recommended configuration:
Listen scope: Conversation or message thread or Entire app for support-only console.
Visibility: participant plus Support/Admin.
Payload visibility: redacted preview.
Preview: conversation active.
Direct App User Chat
Authenticated users can start private chats with each other.
Recommended configuration:
Private app with authenticated users.
Messaging live publish enabled.
Visibility: signed-in users who are allowed to chat.
Empty copy: start a new chat.
Testing Checklist
Before publishing or handing this screen to a customer, test the following.
Troubleshooting
The reply box is missing or disabled
What it usually means:
The screen may not have a selected thread, live publish may be disabled, or the user is not authorized.
What to check:
Select a conversation.
Check Messaging live publish entitlement.
Confirm channel/topic binding.
Confirm the app user is authenticated.
Replies appear in the wrong conversation
What it usually means:
Conversation ID or correlation ID binding is too broad or wrong.
What to check:
Check source binding conversation/correlation.
Use record ID or workflow run ID consistently.
Confirm workflow and screen use the same channel/topic.
No people appear in New chat
What it usually means:
Authenticated user data is not available to the screen.
What to check:
Confirm app is private/authenticated.
Confirm user records exist.
Check direct_chat_users in runtime state if debugging.
Best Practices
Use Conversation for back-and-forth discussion.
Use Notification Center for one-way announcements.
Keep channel/topic naming consistent.
Use correlation IDs tied to stable business objects.
Test as each participant.
Do not use Entire app scope for private customer conversations.
Recommended Default Setup
Use this as a safe first configuration when the maker is unsure.
Listen scope: Conversation or message thread.
Channel: route-specific channel.
Topic: route-specific topic.
Conversation/correlation: stable record or workflow reference.
Visibility: participants plus Admin.
Payload visibility: Redacted preview.
Preview state: Conversation active.