🔗Linked App Exchange
Linked App Exchange 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 Linked App Exchange screen shows requests, replies, payload summaries, and link status for app-to-app communication between NotionApps applications.
Think of this screen as a controlled handoff desk between connected apps. 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 Linked App Exchange 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:
Two NotionApps applications exchange work or status.
A customer-facing app hands requests to an internal app.
A vendor or partner workflow needs visible exchange state.
Makers need to distinguish app-to-app traffic from ordinary conversations.
What The Screen Is For
Use Linked App Exchange when separate apps intentionally share messages, requests, or status updates. It gives users a visible place to acknowledge, claim, complete, or inspect exchange work without leaving their app context.
Good examples:
A customer portal sends requests to an operations app.
A vendor app sends fulfillment updates to a client app.
A headquarters app sends policy tasks to location apps.
A support app escalates cases to product operations.
One app asks another app for missing information.
Bad examples:
Ordinary messages within one app. Use Conversation.
App-wide announcements. Use Notification Center.
General tasks not tied to linked apps. Use Work Queue.
Run health dashboards. Use Operator Console.
Unpermissioned cross-app data sharing.
The Mental Model
A Linked App Exchange 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 see Exchange requests and Application links. Exchange requests can appear as work cards. Application links show configured or active app-to-app connections and payload summaries.
A live Linked App Exchange screen can show:
Exchange request cards with title, status, summary, and details.
Claim, complete, release, or escalate actions on exchange work when rendered as queue items.
Application link cards with status and payload summary.
Empty state for no exchange requests.
Empty state for no application links configured.
Timeline when enabled.
Although the registry default action is Acknowledge, current exchange request cards behave like queue work when they are returned as runtime items. Makers should be clear whether the exchange is just informational or requires ownership/completion.
Required Foundations And Entitlements
Linked App Exchange requires Messaging Foundation and linked application messaging support. Workflow Foundation is recommended when exchanges create tasks, waits, record updates, retries, or escalations.
Automation screen entitlement
Linked App Exchange appears in the Automation group.
Messaging Foundation
App-to-app exchanges are message-backed.
Linked app route/configuration
The screen needs approved app links to show meaningful traffic.
Workflow Foundation, recommended
Most exchange requests need follow-up work or state changes.
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 Linked App Exchange, the maker should name the screen for the user job, not for the internal system. Use names like Partner Requests, App Exchange, Vendor Updates, Customer Portal Requests. 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 Linked App Exchange, the source should usually name the linked application or route. Entire app is useful only for owners monitoring all linked traffic.
Entire app
Use for owner visibility across all linked app exchanges.
Specific screen or form
Use when one form initiates the exchange.
Specific workflow
Use when one workflow owns the handoff.
Conversation or message thread
Use when app exchange is organized by channel/topic.
Linked application
Best default for exchanges with one connected 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 Linked App Exchange, 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 linked applications available to this app.
Checking channels/topics used by exchange routes.
Selecting workflows that process received requests.
Selecting after-action screens for accepted or completed exchanges.
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 Linked App Exchange:
Restrict to users who should see partner/customer/vendor traffic.
Use app-specific roles such as Partner Manager, Operations, Vendor Coordinator, Admin.
Avoid exposing linked app payloads to ordinary users.
Use separate screens for separate partner relationships when needed.
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 relationship or exchange type.
Vendor Updates or Customer Portal Requests
Description
Explains which linked app traffic appears.
Review requests and updates exchanged with connected apps.
Payload visibility
Controls whether exchange payload details are visible.
Redacted preview.
Density
Controls request and link card spacing.
Comfortable.
Show timeline
Shows handoff, acknowledgement, completion, and delivery events.
On for operators.
Require claim before action
Useful when exchange requests require one owner.
On for actionable exchanges, off for informational exchanges.
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
acknowledge
Confirms an exchange has been seen or accepted when configured.
Claim
claim
May appear for runtime exchange items rendered as queue work.
Complete
complete
May finish an exchange request item.
Escalate
escalate
May route unresolved exchange work to a support or exception path.
Decide whether the exchange is informational, acknowledgement-based, or work-based. Use acknowledge for simple receipt. Use claim/complete semantics when a person truly owns the cross-app request.
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 Linked App Exchange, preview these states before publishing:
Live data, to inspect real links.
Empty, to verify no linked app exchanges copy.
Waiting approval or open work, to test exchange request cards.
Overdue, to verify escalation copy.
Operator persona, to verify restricted access.
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 Linked App Exchange should answer:
Are no linked apps configured?
Are linked apps configured but no requests are waiting?
Should the user create a linked route first?
Should support repair a template link?
Common Configuration Patterns
Linked App Exchange should be scoped by relationship so users are not asked to interpret mixed app-to-app traffic.
Customer Portal To Operations
A customer-facing app sends requests into an internal app.
Recommended configuration:
Listen scope: Linked application.
Linked application: customer portal app.
Visibility: Operations/Admin.
Payload visibility: redacted preview.
Require claim before action: on if requests need ownership.
Vendor Fulfillment Updates
A vendor app sends status back to a client app.
Recommended configuration:
Listen scope: Linked application or channel/topic.
Actions: acknowledge informational updates.
Timeline: on.
Visibility: Vendor Coordinator/Admin.
Cross-App Escalation
One app asks another team to resolve missing information.
Recommended configuration:
Listen scope: Specific workflow or linked application.
Action target workflow: escalation workflow.
After-action screen: Conversation or Work Queue.
Payload visibility: redacted preview.
Testing Checklist
Before publishing or handing this screen to a customer, test the following.
Troubleshooting
No application links appear
What it usually means:
Linked app setup is missing, disabled, or not visible to this app.
What to check:
Check linked app route configuration.
Check Messaging dashboard links.
Check Template setup state.
Confirm app IDs were remapped after clone.
Exchange request appears in the wrong app
What it usually means:
Source/target application or channel/topic binding is wrong.
What to check:
Confirm linked application selected.
Check message route source and target.
Verify channel/topic names.
Review recent messages.
Payload is too technical
What it usually means:
Exchange payload summary is exposing raw references.
What to check:
Use redacted preview.
Improve workflow/message payload summary fields.
Keep support references collapsed.
Best Practices
Use Linked App Exchange only for deliberate app-to-app collaboration.
Scope by linked application whenever possible.
Restrict access strongly.
Use redacted payloads by default.
Make ownership semantics explicit.
Test both sending and receiving apps.
Recommended Default Setup
Use this as a safe first configuration when the maker is unsure.
Listen scope: Linked application.
Linked application: selected connected app.
Visibility: Operations/Admin or partner-specific role.
Payload visibility: Redacted preview.
Show timeline: on.
Require claim before action: on only for actionable exchanges.
Preview state: live and empty.