🏠Home
The Home / Today screen is the Everyday chrome landing surface. Its job is to answer one question quickly: what should this user do next? It does that with a built-in recent activity feed, a configurable primary CTA, and a clean empty state when nothing is waiting.
Use Home when you want the app to feel guided on first open. It is especially useful in private apps where users should land on a clear starting point instead of a random data screen.
Who this guide is for Makers adding a Home hub so end users land on next actions instead of a raw list or form. This guide explains every Home builder option in prose, including the related setup that happens outside the small chrome config panel.
What the screen is for
Use Home when
Users need a daily starting point
You want one obvious next-step button
Users should see recent activity without opening the full
Activityscreen
Do not use it when
You need a full Notion record list: use a List screen
You need a shared claim-and-complete desk: use Work Queue
You need a personal workflow inbox: use My Queue
You need an operations health surface: use Operator Console
Good examples include a service app that lands on Submit request, an onboarding portal that starts with Begin intake, or an automation-heavy app that opens with an Automation Launcher.
What users see in the live app
When Home has content, the runtime can show:
The screen title and description
A large primary CTA button when a target screen is configured
A recent activity section populated from the end-user activity feed
When there is no activity and no CTA, users see the empty state instead.
Display title
Home
Empty title
Nothing waiting today
Empty description
Assigned work and queue items will show up here.
Empty action label
Get started
Primary CTA screen
None
Entitlement
None
Add Home in the builder
Open Screens → + New Screen.
Choose a Notion database as the context anchor.
Under Everyday chrome, select Home / Today.
Click Done.
Configure the empty-state fields and, if needed, the primary CTA.
Place Home in navigation, usually first.
Publish before live testing.
Complete Builder Options Reference
Home uses the lightweight chrome config panel. That panel is intentionally small, so the important setup is a combination of the visible fields, a few built-in defaults from the registry, and some builder actions outside the panel.
Screen identity
This section explains the parts that define what Home is before you customize the copy.
Screen type
What it does:
This identifies the screen as Home and tells the runtime to load Home behavior: recent activity plus an optional primary CTA.
How to use it:
You choose Home / Today from the picker when you create the screen. After that, treat the behavior as fixed. If you really need a search surface or a settings surface, add Search or Profile instead of trying to stretch Home into a different role.
Why / recommended default: Home works best when it stays focused on orientation and next steps. A common mistake is expecting it to behave like a list or a queue desk, which makes the screen feel too thin for the job.
Title and description defaults
What it does: Home starts with built-in display text from the chrome registry. The runtime uses that text for the screen’s hero area.
How to use it:
Keep the label short and user-facing. Home and Today are both good. If you rename the screen elsewhere in the builder, use language the end user would understand immediately.
Why / recommended default: The landing screen should feel universal and calm. A common mistake is naming it after an internal team, process, or sheet, which makes the app feel like builder scaffolding instead of product UX.
Empty state
These fields control what the user sees when Home has nothing to show yet. That includes a brand-new app, a quiet moment in the day, or a setup where no recent activity exists yet.
Empty state title
What it does: This is the headline shown when Home has no recent activity and no CTA content to display.
How to use it:
Use a reassuring sentence such as Nothing waiting today. The title should tell the user the state is normal, not broken.
Why / recommended default:
Most apps will hit this state during QA or quieter periods. A calm title keeps the experience trustworthy. A common mistake is using technical wording like No records found, which sounds like a failed search instead of a healthy dashboard.
Empty state description
What it does: This describes what will eventually appear on Home when the app becomes active.
How to use it: Tell users what kinds of items belong here, such as assigned work, queue items, or recent updates. Keep it plain-language and short enough to read quickly on mobile.
Why / recommended default: The description is your chance to teach the screen’s purpose. The recommended default is the registry text, because it already explains the screen without over-promising. A common mistake is writing generic filler copy that does not tell users what Home is for.
Empty action label
What it does:
This is the label the runtime uses for the Home CTA button. By default, Home uses Get started.
How to use it: Know that this value comes from the registry default and is often not editable in the panel. In practice, you usually shape the CTA experience by choosing the right target screen, not by trying to rename the button in this config.
Why / recommended default:
Get started is a safe default because it works for many first actions. The common mistake is assuming the button label is a fully configurable field when the more important setup choice is the destination screen.
Home-only action
This is the one builder control that is unique to Home.
Primary CTA screen
What it does: This tells Home which screen to open when the user taps the main CTA button.
How to use it:
Point it at the action users perform most often. In the current picker, the practical choices are Create Form screens and Automation Launcher screens. Leave it blank only if you intentionally want Home to be passive and informational.
Why / recommended default: The recommended default is to set this to the most common starting action in the app. That makes Home immediately useful. A common mistake is pointing it to a secondary flow or leaving it unset, which makes the landing screen feel incomplete.
Maker tip If you can only pick one strong action for Home, choose the form or launcher users open most often. Home should reduce hesitation, not present a menu of competing options.
Related setup outside chrome config
Home only works well when you also set up navigation, publish flow, and preview correctly.
Edit Navigation
What it does: This determines whether Home appears in the app’s main navigation and where it sits relative to other screens.
How to use it: Put Home first in side navigation or the first primary tab in most private apps. If the app has role-based shells, make sure each audience still has an obvious landing surface.
Why / recommended default: Home is the most natural landing destination for many apps. The common mistake is adding Home but burying it behind other screens, which weakens the whole point of having a landing hub.
Publish
What it does: This pushes the Home configuration into the live app so end users can actually use it.
How to use it: Publish after checking the CTA target and empty-state copy in preview. If the CTA points to a newly added form or launcher, make sure that target screen is also published.
Why / recommended default: A Home CTA that works in builder but not live is usually a publish gap, not a Home bug. The common mistake is testing half-configured navigation or unpublished targets.
View as user
What it does: This lets you preview Home as a real end-user persona rather than only as the maker.
How to use it:
Use View as user when testing private apps, especially if recent activity, permissions, or role-based screen visibility could change what appears.
Why / recommended default: Home is identity-sensitive because the activity feed is user-contextual. A common mistake is validating Home only as the maker and missing that another role sees no CTA, the wrong activity, or a different landing flow.
Navigation and publish as separate concerns
What it does: These are not the same step. Navigation decides whether the screen is reachable. Publish decides whether live users can see the latest version.
How to use it: Treat both as required steps. First place Home in navigation, then publish, then test the published result.
Why / recommended default: Many “Home is missing” or “Home did not update” reports come from skipping one of these steps. The common mistake is fixing copy in the panel and assuming users will see it immediately.
Recommended default setup
Empty state title
Nothing waiting today
Empty state description
Assigned work and queue items will show up here.
Primary CTA screen
Main Create Form or Automation Launcher
Navigation
First primary screen
Testing checklist
Troubleshooting
Home always looks empty
No recent activity and no CTA target
Submit a test record and confirm Primary CTA screen is set
CTA button is missing
No target screen selected
Pick a Create Form or Automation Launcher
CTA appears but opens the wrong place
Wrong target screen configured
Recheck which screen ID was selected in the Home config
Users do not land on Home by default
Navigation order or Profile prefs override it
Put Home first in navigation and confirm user landing prefs in Profile
Maker sees content but users do not
Persona / auth difference
Re-test with View as user
Best practices
Keep Home focused on one next step, not many competing actions.
Pair Home with
Profileso users can later choose a different landing screen if needed.Use
My QueueorActivityfor deeper workflow surfaces instead of overloading Home.