> For the complete documentation index, see [llms.txt](https://docs.notionapps.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.notionapps.com/screens-and-components/types-of-screens/everyday-chrome-screens/home.md).

# 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.

{% hint style="info" %}
**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.
{% endhint %}

## 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 `Activity` screen

### 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.

| Default            | Value                                            |
| ------------------ | ------------------------------------------------ |
| 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

1. Open **Screens → + New Screen**.
2. Choose a Notion database as the context anchor.
3. Under **Everyday chrome**, select **Home / Today**.
4. Click **Done**.
5. Configure the empty-state fields and, if needed, the primary CTA.
6. Place Home in navigation, usually first.
7. Publish before live testing.

![Builder configuration for this screen](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FtNWljiBBk539yXIZ2j3v%2Feveryday-chrome__home__00-builder-hero.jpg?alt=media)

![End-user preview of this screen](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2Fc7JE2NWQ7DnW9mbtZNn8%2Feveryday-chrome__home__09-preview-closeup.jpg?alt=media)

## 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.

![Annotated builder screenshot: Chrome config](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FTKJlq4uLJfcawXkUwAqK%2Feveryday-chrome__home__01-section-chrome-config.jpg?alt=media)

### 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

![Annotated builder screenshot: Empty state title](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FwJ7QsinkHUsQRCbr310S%2Feveryday-chrome__home__02-section-empty-state-title.jpg?alt=media)

**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

![Annotated builder screenshot: Empty state description](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FvMdTuvhdtcxpy0xlBT4X%2Feveryday-chrome__home__03-section-empty-state-description.jpg?alt=media)

**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

![Annotated builder screenshot: Primary CTA screen](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FnVoxe4x5acwkGUNGp1ma%2Feveryday-chrome__home__04-section-primary-cta-screen.jpg?alt=media)

**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.

{% hint style="success" %}
**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.
{% endhint %}

### 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

| Setting                 | Recommended value                                |
| ----------------------- | ------------------------------------------------ |
| 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

* [ ] Home appears in navigation after publish, because placement is separate from creation
* [ ] The empty-state title and description read clearly on phone and desktop, because Home is often a first impression
* [ ] The primary CTA opens the intended `Create Form` or `Automation Launcher`
* [ ] Recent activity appears after a real submit, message, or decision so the feed is proven, not assumed
* [ ] The activity feed does not expose items a different user should not see
* [ ] `View as user` confirms the right landing experience for each persona

## Troubleshooting

| Symptom                               | Likely cause                                  | What to check                                                            |
| ------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------ |
| 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 `Profile` so users can later choose a different landing screen if needed.
* Use `My Queue` or `Activity` for deeper workflow surfaces instead of overloading Home.