🖥️Everyday Chrome Screens
Everyday chrome screens are the always-available utility surfaces you add from Screens → + New Screen → Everyday chrome. They are not standard Notion list, details, or form screens. Instead, they give the end-user app a familiar shell: a landing surface, a search surface, and a preferences surface.
Use this screen family when you want the app to feel guided instead of dumping people into a raw database view. In most private apps, these are the screens that make the app feel finished.
My Queue and Activity are related, but they do not live in the Everyday chrome group. They live in Queue & activity because they depend on Workflow, Messaging, or Approval Management. See Queue & Activity Screens.
Where to find them In the builder, open Screens → + New Screen. Under Everyday chrome, pick Home / Today, Search, or Profile. Choose a Notion database as the context anchor, then click Done.
Screen guide index
Give users a clear starting point, recent activity, and one main next step
You want users to land on “what should I do now?”
Let users pick a landing screen, manage notification prefs, and log out
You want built-in user preferences without building a custom settings screen
Related guides
My Queue
Activity
How Everyday chrome differs from other screen families
Everyday chrome is for app shell behavior, not record management. That distinction matters because makers often try to use Home, Search, or Profile like a list or a workflow desk and end up fighting the product.
Data screens
Browsing, creating, and editing Notion-backed records
Everyday chrome
Home, search, and profile surfaces that help users move around the app
Queue & activity
Personal feeds for “what needs me?” and “what changed?”
Automation / operational screens
Action-heavy runtime surfaces like Work Queue, Decision, Operator Console, and Workflow Status
Complete Builder Options Reference
The Everyday chrome family uses a lightweight chrome config panel. That panel is intentionally smaller than the config for list, form, or automation screens, so the important setup work is split between the panel itself and a few builder actions outside the panel.
Shared chrome config fields
These are the fields makers will see, or inherit, across the Everyday chrome family. Some are directly editable in the panel and some are defaults the runtime uses even though the panel does not expose them yet.
Screen type
What it does:
The screen type determines whether the runtime behaves as Home, Search, or Profile. This is the core identity of the screen and controls which built-in behavior loads.
How to use it: You choose the screen type when you add the screen from the Everyday chrome picker. After that, think of the type as fixed behavior, not a cosmetic label. If you need a different job, add the correct screen rather than trying to force one chrome screen to act like another.
Why / recommended default:
Pick the screen based on the user job, not the name of the database you happened to choose as the context anchor. A common mistake is adding Search when the real need is a filtered list, or adding Home when the real need is a shared operations desk.
Title and description defaults
What it does: Each chrome screen starts with registry defaults for its title and descriptive copy. Those defaults shape the header and empty-state framing the runtime shows.
How to use it:
Treat the built-in wording as a starting point. If the builder exposes renaming elsewhere, keep the final wording user-facing and short. Use labels like Home, Today, Search, or Profile, not internal project names or database jargon.
Why / recommended default: Simple labels help users understand the app immediately. A common mistake is naming the screen after an internal team or sheet, which makes navigation feel technical and confusing.
Empty state title
What it does: This is the headline shown when the screen has no content to render yet.
How to use it: Write one short sentence that tells the user the current state without blame or panic. Good empty titles sound calm and expected.
Why / recommended default:
Empty states happen often during onboarding, QA, and quiet periods. A reassuring title keeps the screen from feeling broken. A common mistake is writing something too technical, like No records returned.
Empty state description
What it does: This explains what will appear on the screen later, or what the user can do next.
How to use it: Use plain language and explain the value of the screen. Mention the type of content users should expect, such as assigned work, records, preferences, or notifications.
Why / recommended default: The description is where you reduce confusion for first-time users. A common mistake is leaving the description too vague, which makes the screen feel unfinished even when it is working correctly.
Empty action label
What it does: This is the label the runtime uses for the empty-state action when that screen supports one. The default comes from the chrome registry.
How to use it:
Know that this value often exists at runtime even when the builder panel does not expose it for editing. For example, Home defaults to Get started, Search defaults to Scan, My Queue and Activity default to Refresh, and Profile defaults to Save.
Why / recommended default: This matters because makers sometimes expect every button label to be editable from the panel. In this screen family, that is not always true. The common mistake is trying to “fix” the label when the better move is to configure the target screen or the surrounding copy correctly.
Shared builder actions outside chrome config
These are not part of the small chrome config panel, but they are still part of the real setup. If you skip them, the screen may be technically added but still unusable in the app.
Edit Navigation
What it does: This controls whether the screen actually appears in the app’s side navigation, tab bar, or other primary navigation surfaces.
How to use it:
After adding a chrome screen, place it where users will expect it. In most apps, Home goes first, Search sits near the main working surfaces, and Profile goes last or under a More area.
Why / recommended default: Navigation placement is part of the product design, not an afterthought. A common mistake is adding a screen and forgetting to put it in navigation, which makes the maker think the screen failed when it was simply never surfaced.
Publish
What it does: Publishing pushes the builder changes into the live app experience so end users can actually open the screen.
How to use it: Publish after you finish configuration and after a quick preview pass. If you are testing multiple chrome screens, publish them together so the whole shell feels coherent.
Why / recommended default: Chrome screens are especially sensitive to “it works in builder but not live” confusion. The most common mistake is testing in one environment and forgetting that the live app still needs a publish.
View as user
What it does: This lets you preview the app as a specific end user while testing. It is especially important for screens whose content depends on identity, permissions, or end-user preferences.
How to use it:
Use View as user whenever you need to validate personal behavior such as activity visibility, queue visibility, landing-screen choices, or authenticated preferences.
Why / recommended default: Builder preview by itself can hide role-specific issues. A common mistake is testing only as the maker and assuming the same content or options will appear for staff, clients, approvers, or other personas.
Screen-specific options
Some options only exist on one Everyday chrome screen.
Home primary CTA screen
What it does:
On Home, the primary CTA tells the big main button where to go.
How to use it:
Point it at the most important next-step screen, typically a Create Form or Automation Launcher.
Why / recommended default: Home works best when it answers “what should I do next?” immediately. The common mistake is leaving the CTA empty and then wondering why Home feels passive.
Search sheet scope
What it does:
On Search, the runtime can optionally limit results to certain sheet IDs through searchSheetIds.
How to use it:
Leave it empty unless you have a strong reason to restrict search. The current builder panel only shows a hint about scope, and the picker is not fully exposed there, but the runtime still honors searchSheetIds when it exists in layout JSON.
Why / recommended default: Broad search is usually what users expect. A common mistake is narrowing scope so much that users believe Search is broken because the record they know exists is excluded.
Choosing the right screen
Maker tip Start most private apps with Home and Profile. Add Search once users need cross-database lookup. Add My Queue and Activity from the separate Queue & activity group when automation is enabled and users need personal work feeds or history.
Shared setup steps
Open the app in the builder.
Go to Screens.
Click + New Screen.
Pick a Notion database as the context anchor.
Under Everyday chrome, select
Home / Today,Search, orProfile.Click Done.
Configure the empty-state fields and any screen-specific options.
Use Edit Navigation so the screen is actually reachable.
Preview in builder, including View as user when the screen is user-specific.
Publish before live testing.
Safe defaults
Put
Homefirst in primary navigation for most private apps.Keep
Searchbroadly scoped unless there is a clear data-boundary reason not to.Put
Profilelast or under aMorearea.Keep empty-state copy plain-language and calm.
Test both builder preview and the published app before rollout.