🚨Exception Resolution 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 Exception Resolution screen is a recovery screen for failed steps, missing data, blocked routes, retries, and manual fixes.
Think of this screen as A repair desk for broken automation — diagnose, resolve, or escalate.
Who This Guide Is For
This guide is for makers configuring an Exception Resolution 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:
Operators must clear failed workflow steps.
Blocked routes need a human fix before continuing.
Failed work should escalate into another workflow.
What The Screen Is For
Use Exception Resolution when
Operators must clear failed workflow steps.
Blocked routes need a human fix before continuing.
Failed work should escalate into another workflow.
Do not use it when
Normal approvals — use Decision.
Ordinary task completion — use Work Queue.
Passive monitoring only — use Operator Console / Workflow Status.
What Users See In The Live App
Exception cards with failure reason and related run context.
Mark resolved and Escalate actions.
Timeline of failure and recovery events when enabled.
Default listen scope
Entire app
Require claim before action
Off
Default preview persona / state
Technician / Live
Empty title
No exceptions need attention
Empty description
Failed workflow work and unresolved exceptions appear here.
Required Foundations
Automation screen entitlement
Exception Resolution appears in the Automation / Operational group.
Workflow, optional Messaging
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. Each option is explained in prose so makers can configure an exception desk that is safe for operators, narrow enough to be useful, and clear about what recovery actions are allowed.
Header and screen type
This section defines the repair desk at a glance. Exception Resolution works best when the name tells operators they are fixing blocked automation, not handling ordinary intake work.
Screen type
What it does: Sets the native behavior to Exception Resolution, which renders workflow failures, blocked steps, and manual recovery state. How to use it: Keep the screen type as Exception Resolution. Use Work Queue for normal human work and Decision for structured approvals. Why / recommended default: Exception desks should stay focused on recovery. Mixing them with general work makes the most urgent problems harder to spot.
Category
What it does: Places the screen in the native Automation or Operational grouping. How to use it: Keep the default grouping and locate the screen near other operator tools in navigation. Why / recommended default: Good organization helps makers keep operational recovery surfaces distinct from day-to-day desks.
Title
What it does: Sets the live title.
How to use it: Use clear names like Exception resolution, Automation recovery, or Ops repair desk.
Why / recommended default: A clear title helps users understand that the items here are broken states that need intervention.
Description
What it does: Adds the helper sentence below the title. How to use it: Tell operators what they should do, such as "Review blocked automation, mark resolved after a manual fix, or escalate when deeper recovery is needed." Why / recommended default: Good description text helps distinguish this screen from a normal queue.
Automation source
This section controls which failures appear on the desk. A well-scoped exception screen should make urgent issues obvious without flooding operators with every event in the app.
Listen scope
What it does: Chooses the top-level source of exceptions shown on the screen. How to use it: Use Specific workflow when one team owns recovery for one process. Use Entire app only for a shared operations desk covering many workflows. Why / recommended default: Specific workflow is usually the clearest default. Entire app is valuable for central ops teams, but it gets noisy quickly.
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 form or screen whose downstream automation may fail and should route to this desk. Why / recommended default: This is helpful when support teams think in terms of the entry point users touched rather than the internal workflow name.
Workflow
What it does: Filters the desk to exceptions from one workflow. How to use it: Pick the published workflow your operators are responsible for recovering. Why / recommended default: This setting is the simplest way to keep a recovery desk understandable.
Messaging channel
What it does: Narrows exception-related context to one messaging channel when recovery is paired with routed messages. How to use it: Set it only when messaging is part of the failure-handling design. Why / recommended default: Extra channel filtering is only useful when it reflects the actual route design. Otherwise it just creates one more way to hide the exceptions you need.
Topic
What it does: Narrows message-linked activity to one topic. How to use it: Match the exact topic when recovery messages or alerts are topic-specific. Why / recommended default: Topic mismatch is a common reason a repair desk looks empty even though the workflow failed.
Conversation or correlation
What it does: Limits the desk to one case or thread context. How to use it: Use this only for case-specific recovery experiences, not for a reusable ops desk. Why / recommended default: Most exception desks should remain reusable. Over-filtering by correlation makes them too brittle.
Linked application
What it does: Binds the desk to a linked NotionApps app when failures happen in an app-to-app exchange. How to use it: Choose the linked app only when cross-app recovery really matters. Why / recommended default: Cross-app recovery is valid, but it is not the normal starting point for this screen.
App audience and notification prefs
Exception desks should almost always be restricted, and they often intersect with tenant boundaries and operator-notification policy. These app-level settings help keep recovery work visible to the right people only.
Tenant mode
What it does: Decides whether runtime visibility is partitioned by tenant relation. How to use it: Use Relation when support teams should only see failures for their own client or operating group. Use Off only when the app is truly single-tenant or internally shared. Why / recommended default: Tenant isolation is often safer than people expect, especially when exception payloads contain sensitive business details.
Tenant field
What it does: Selects the Users-sheet relation that defines tenant membership. How to use it: Pick the same client, company, or workspace field used across the rest of the app. Why / recommended default: Consistent tenant modeling keeps recovery screens aligned with every other protected surface.
Role field
What it does: Tells the platform which field holds a user's role when it is not named Role.
How to use it: Set it only for custom user schemas.
Why / recommended default: A wrong role-field mapping can quietly open the desk to the wrong audience or hide it from the right one.
Notification categories
What it does: Maps operator-facing notification categories to user preference fields. How to use it: Use only real categories, such as recovery alerts or escalation notices, that the automation system actually sends. Why / recommended default: Clean category design makes exception handling more predictable and easier to support.
Add notification category
What it does: Adds another category row. How to use it: Add one only when you also have a sender and preference field to connect to it. Why / recommended default: Unused categories make policy harder to understand without improving recovery.
Save audience policy
What it does: Saves tenant and notification preference policy at the app level. How to use it: Save after every policy change and before testing with another operator persona. Why / recommended default: Unsaved policy often looks like a screen bug when it is really just a missed save.
Template setup state
This diagnostic section matters most after templates are cloned or demos are repaired.
Setup state indicator
What it does: Reports whether bindings look provisioned, need review, or have no setup report. How to use it: Treat Needs review as a prompt to verify the recovery workflow bindings before trusting the desk. Why / recommended default: Template drift is a common cause of missing exceptions, and this indicator gives you an early warning.
Related context
This panel helps you find the forms, workflows, and follow-up screens that belong to the same recovery flow.
Related context panel
What it does: Shows discovery counts and related runtime objects. How to use it: Use it to locate the originating workflow, a related status screen, or a Conversation screen operators may need during triage. Why / recommended default: Context discovery reduces guesswork and helps you wire a coherent recovery experience.
Visibility and access
Exception desks should be tightly controlled. The screen may expose failure details, payloads, or operational clues that ordinary users should never see.
Visibility rules
What it does: Applies condition-based visibility logic. How to use it: Restrict the screen by role, team, and tenant so only support, operations, or admin users can open it. Why / recommended default: Broad access is almost always a mistake here. Exception data is operationally sensitive.
Allowed role names
What it does: Adds a role allow list.
How to use it: Use concise roles such as Operator, Support, Admin.
Why / recommended default: A direct role list is usually the cleanest access model for repair desks.
Allowed users
What it does: Grants access to named people. How to use it: Use for temporary pilots or break-glass operators only. Why / recommended default: Per-user overrides are useful, but they should stay exceptional.
Display and action policy
These settings control how much failure detail operators can see and whether the desk behaves like a lean triage list or a more investigative recovery console.
Screen title override
What it does: Refines the user-facing title. How to use it: Use wording that clearly signals operational repair work. Why / recommended default: Operators should understand at a glance that the screen is about broken automation, not normal throughput.
Description
What it does: Sets the helper copy below the title. How to use it: Tell operators to diagnose, resolve, or escalate as appropriate. Why / recommended default: A precise description helps teams use the right recovery path instead of improvising.
Payload visibility
What it does: Controls whether operators see metadata only, a redacted preview, or full payload detail. How to use it: Use Redacted preview for most operator desks and Full payload only for the trusted teams who truly need the underlying detail to recover failures. Why / recommended default: Recovery often needs more context than requester screens, but Full payload should still be deliberate, not automatic.
Density
What it does: Chooses comfortable or compact spacing. How to use it: Use Comfortable when failures are complex and need careful reading. Use Compact when an experienced ops team is handling high volume. Why / recommended default: Comfortable layouts reduce missed clues; compact layouts support speed once the process is stable.
Show timeline
What it does: Shows the sequence of workflow, message, and audit events around the exception. How to use it: Leave On for most Exception Resolution screens. Operators usually need the history to understand what actually failed. Why / recommended default: Timeline context is one of the highest-value tools in recovery. Turning it off usually slows triage.
Require claim before action
What it does: Controls whether someone must claim an exception before acting on it. How to use it: The registry default is Off. Leave it off when the desk is already owned by a small trusted team, or turn it on if duplicate recovery work becomes a real problem. Why / recommended default: Off is a reasonable default for many ops desks because speed matters, but shared larger teams may benefit from explicit ownership locks.
Available actions
This section defines how operators move an exception out of the unresolved state. The two core actions are different on purpose: one clears the issue after a fix, and the other starts a deeper recovery route.
Mark resolved
What it does: Clears the exception after the operator has handled the manual fix. How to use it: Use this when the operator corrected the underlying issue outside the screen or confirmed the workflow can be considered resolved. Train the team on what evidence is required before marking something resolved. Why / recommended default: Mark resolved should be the clean path for ordinary recoveries. The common mistake is using it too early, before the real cause is actually addressed.
Escalate
What it does: Starts a deeper recovery or incident workflow from the exception item. How to use it: Keep Escalate available when failures sometimes require a second-line process, another team, or a more formal response. Why / recommended default: Escalate is valuable because not every failure should be closed locally. It turns an unresolved exception into an auditable recovery handoff.
After-action screen
What it does: Routes the operator to another screen after resolving or escalating. How to use it: Send operators to Workflow Status when they need to confirm the route recovered, or to Conversation when follow-up communication is standard. Why / recommended default: This is optional. Use it only when the next step is predictable enough to justify an automatic redirect.
Target workflow
What it does: Supplies the destination workflow for Escalate. How to use it: Bind the published recovery workflow that should start when the operator escalates. Why / recommended default: This setting matters a lot. If Escalate exists but no target workflow is set, the action will not do the job operators expect.
Preview scenario
Preview controls help makers test whether the desk feels useful when something is actually broken.
Device and orientation
What it does: Changes the preview frame across desktop, tablet, and mobile sizes. How to use it: Test the screen on desktop first, then check mobile if field operators or support staff may use it on the go. Why / recommended default: Recovery work often happens under time pressure, so layout problems matter more than usual.
Test persona
What it does: Simulates the viewer role. How to use it: Test with the real operator or support persona rather than only as Admin. Why / recommended default: Admin preview can hide access problems that would block the actual recovery team.
Preview state
What it does: Simulates states such as Live, Empty, Error, or Overdue. How to use it: Check Live, Error, and Empty so you know the desk still feels understandable under pressure. Why / recommended default: The default preview state is Live, which is good for core behavior, but recovery screens also need a strong empty and failure presentation.
Test mode
What it does: Switches between simulated preview and live testing. How to use it: Use live testing with a real failed run before publish so you can verify the action buttons and timeline against actual exception data. Why / recommended default: Simulated preview is useful, but live failure testing is what proves the desk is ready.
Empty state and sample data
Even operator desks should look intentional when there is nothing to fix.
Empty title
What it does: Sets the headline shown when no unresolved exceptions match the current scope.
How to use it: Keep the default No exceptions need attention unless your team uses a clearer phrase.
Why / recommended default: The default sounds healthy and complete, which is ideal for a recovery desk.
Empty description
What it does: Explains what kinds of failures would appear here.
How to use it: Keep or adapt the default Failed workflow work and unresolved exceptions appear here.
Why / recommended default: Helpful empty copy reassures operators that the system is quiet, not broken.
Sample item, run, or conversation
What it does: Provides builder-only sample references for realistic preview. How to use it: Use a sample with an actual failure reason and timeline context so you can confirm the desk is useful before a real incident happens. Why / recommended default: Exception screens are hard to judge with toy data. Good samples make the preview much more trustworthy.
Recommended Default Setup
Listen scope
Specific workflow for one process; Entire app for ops
Visibility
Operator, Support, Admin
Payload visibility
Redacted or Full for trusted operators
Show timeline
On
Escalate target workflow
Bind a recovery/escalation workflow
Common Configuration Patterns
Process-specific recovery
Specific workflow + Mark resolved.
Ops escalation desk
Entire app + Escalate bound to an incident workflow.
Testing Checklist
Troubleshooting
Exceptions never appear
Failures are not producing exception items, or listen scope excludes them.
Escalate does nothing
Target workflow is not set on the Escalate action.
Best Practices
Configure Exception Resolution 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.