> 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/profile.md).

# Profile

The **Profile** screen is the Everyday chrome preferences surface. It lets end users pick a default landing screen, control notification preferences, save those preferences, and log out of the app.

Use `Profile` when you want built-in user preferences without building a custom settings workflow on top of a Notion users database. It is especially important in private apps where users should control where they land after sign-in.

{% hint style="info" %}
**Who this guide is for**\
Makers who need a built-in settings page instead of a custom form. This guide explains every Profile-related option in prose, including the runtime preferences users control and the maker setup those preferences depend on.
{% endhint %}

## What the screen is for

### Use Profile when

* Users need to choose which primary screen opens after login
* Users should toggle in-app or email notifications for themselves
* Users need a clear `Log out` path in a private app

### Do not use it when

* You need to edit user record fields such as role or phone number: use an **Update Form**
* You want builder-only app settings such as branding or maker preferences
* You need identity-provider administration such as SSO or password reset flows

## What users see in the live app

Profile can show:

* A list of primary screens the user can choose as the default landing screen
* Notification toggles for in-app and email delivery
* A `Save preferences` button
* A `Log out` button

| Default            | Value                                                           |
| ------------------ | --------------------------------------------------------------- |
| Display title      | Profile                                                         |
| Empty title        | Your profile                                                    |
| Empty description  | Set notification preferences and choose where the app opens.    |
| Empty action label | Save                                                            |
| Entitlement        | None                                                            |
| Prefs API          | Auth-only; public apps without a signed-in user skip prefs load |

## Add Profile in the builder

1. Open **Screens → + New Screen**.
2. Choose a Notion database as the context anchor.
3. Under **Everyday chrome**, select **Profile**.
4. Click **Done**.
5. Put Profile somewhere predictable, usually last in navigation or under `More`.
6. Publish before end-user testing.

![Builder configuration for this screen](https://4233028229-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5ZqDXcVVffWUqEIZVhmn%2Fuploads%2FdgblaOJyYuFFArtPOmYK%2Feveryday-chrome__profile__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%2FhsUY3u30jqgCGUMPhUtt%2Feveryday-chrome__profile__09-preview-closeup.jpg?alt=media)

## Complete Builder Options Reference

Profile uses the same lightweight chrome config panel as Home and Search, but most of its important behavior happens at runtime through end-user preferences. That means good maker setup matters even more than visible panel fields.

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

### Screen identity

This section explains what makes Profile a built-in preferences surface rather than a generic data screen.

#### Screen type

**What it does:**\
This identifies the screen as `Profile` and tells the runtime to load built-in preferences and logout behavior.

**How to use it:**\
Choose `Profile` from the Everyday chrome picker when the job is user preferences. Do not use it as a substitute for a Notion-backed user profile form if you need editable user fields.

**Why / recommended default:**\
Profile is best when it stays focused on app preferences. A common mistake is expecting it to manage all user data, which leads makers to look for fields and controls that belong on a normal form screen instead.

#### Title and description defaults

**What it does:**\
The registry provides the default title and descriptive framing for the Profile screen.

**How to use it:**\
Keep the name obvious. `Profile` is usually the right choice because users already understand what settings or account areas usually live there.

**Why / recommended default:**\
Settings surfaces should be easy to find. A common mistake is renaming Profile to something abstract like `Preferences Hub` when plain language would be clearer.

### Empty state

These values supply the screen’s baseline copy and save-action framing.

#### 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%2FeJ81wIngAklwrnd8Urc9%2Feveryday-chrome__profile__02-section-empty-state-title.jpg?alt=media)

**What it does:**\
This provides the default heading for the screen.

**How to use it:**\
Use a direct label like `Your profile`. Because Profile is not a feed-based screen, the copy should feel personal and stable rather than reactive.

**Why / recommended default:**\
The recommended default works because it immediately signals ownership. A common mistake is using workflow language here, which makes the settings page sound like another work surface instead of a personal preferences area.

#### 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%2FQCMDOtrpD9e9rRUhmdmH%2Feveryday-chrome__profile__03-section-empty-state-description.jpg?alt=media)

**What it does:**\
This explains what the user can control on the Profile screen.

**How to use it:**\
Mention the two big jobs: choosing where the app opens and setting notification preferences. Keep it short and human.

**Why / recommended default:**\
This description helps users understand why Profile matters. A common mistake is describing only one preference area and leaving the other as a surprise.

#### Empty action label

**What it does:**\
The registry default associated with Profile is `Save`.

**How to use it:**\
Treat this as a runtime default rather than a fully exposed panel field. The visible button text users interact with is `Save preferences`, and the important maker task is making sure the preference choices are useful and testable.

**Why / recommended default:**\
The key decision is not the wording of the save affordance, but whether the user has meaningful options to save. A common mistake is assuming the button label is the primary customization lever.

### End-user preferences at runtime

These are the controls the user sees on Profile. They are not all directly configurable in the chrome config panel, but the maker still needs to understand and support them.

#### Default landing screen

**What it does:**\
This lets the user choose which screen the app should open after sign-in or after preferences load.

**How to use it:**\
Only screens marked as **primary** in navigation appear in this list. If you want a screen to be a landing choice, mark it primary in `Edit Navigation`. Good candidates are `Home`, `My Queue`, and other role-specific hubs.

**Why / recommended default:**\
This setting gives users control over how they start their day. The recommended maker setup is to expose only a small set of strong landing candidates. A common mistake is forgetting to mark screens as primary, which makes the landing list look empty or incomplete.

#### In-app notifications

**What it does:**\
This lets users toggle whether they receive notifications inside the app.

**How to use it:**\
Offer this when your app generates meaningful in-app notices and users need personal control. Test it with real notification-producing flows rather than assuming the toggle is enough.

**Why / recommended default:**\
In-app notifications are usually a good default because they are contextual and less intrusive than email. A common mistake is enabling a notification-heavy workflow but never checking whether the toggle meaningfully affects the experience.

#### Email notifications

**What it does:**\
This lets users opt in or out of email-based notifications.

**How to use it:**\
Use email when the audience expects follow-up outside the app or may not be logged in continuously. For many internal apps, leaving email off by default is a safer starting point unless the business process depends on it.

**Why / recommended default:**\
Email can be useful, but it also creates noise faster than in-app alerts. A common mistake is assuming every audience wants email the same way, which often leads to alert fatigue.

#### Save preferences

**What it does:**\
This persists the user’s selected landing screen and notification settings through the prefs API.

**How to use it:**\
Test the full save cycle: change a setting, tap `Save preferences`, reload, and confirm the new state sticks. Make sure users know their changes are not final until they save.

**Why / recommended default:**\
The runtime does not treat preference changes as automatically committed. A common mistake is toggling options in preview, navigating away, and thinking the system lost the change when it was never saved.

#### Log out

**What it does:**\
This ends the end-user session.

**How to use it:**\
Always validate logout in the same auth setup your users will use in production. That is especially important for private apps with external auth hosts or SSO-related flows.

**Why / recommended default:**\
Logout is a trust feature as much as a security feature. A common mistake is adding Profile but never testing whether logout returns the user to the correct signed-out state.

{% hint style="success" %}
**Maker tip**\
If you want users to choose a landing screen, mark those candidate screens as **primary** first. Profile only lists primary screens in the default landing picker.
{% endhint %}

### Related setup outside chrome config

Profile is only as good as the surrounding navigation and auth setup.

#### Edit Navigation

**What it does:**\
This controls whether Profile appears in the app shell and which screens count as primary landing candidates.

**How to use it:**\
Put Profile in a predictable place, usually last in a side nav or under `More` on mobile. Separately, make sure the screens you want available for landing selection are marked primary.

**Why / recommended default:**\
Navigation setup affects two things at once: discoverability of Profile itself and the contents of the landing-screen picker. A common mistake is handling only one of those.

#### Publish

**What it does:**\
Publishing makes Profile and any related navigation changes live.

**How to use it:**\
Publish after you configure both Profile and the primary screens it should reference. Then test in the live app, not just the builder preview.

**Why / recommended default:**\
Profile bugs are often really navigation or publish mismatches. A common mistake is changing a screen’s primary status in builder and forgetting that the live picker will not update until publish.

#### View as user

**What it does:**\
This lets you preview Profile as a specific end user, including role-based visibility and auth-sensitive behavior.

**How to use it:**\
Use `View as user` when checking which landing choices appear, how preferences load, and whether notification settings make sense for different personas.

**Why / recommended default:**\
Profile behavior depends on the user context. A common mistake is validating only as the maker and missing that another role has no landing options or a different visible screen set.

#### Public-app auth limitation

**What it does:**\
The prefs API is auth-only. In public apps without a signed-in end-user token, runtime preference loading is skipped.

**How to use it:**\
If you are testing Profile in a public shell, know that preference persistence may not behave the same way as in a private signed-in app. Use a real authenticated context or `View as user` when available.

**Why / recommended default:**\
This avoids false bug reports. A common mistake is treating public-preview behavior as proof that preferences are broken when the screen is intentionally auth-dependent.

## How landing screen works

1. The user opens `Profile`.
2. They choose one of the primary screens listed under `Default landing screen`.
3. They tap `Save preferences`.
4. On the next app start, the runtime uses that saved preference when the chosen screen is still available to that user.

If no preference is saved, the app falls back to its normal default navigation behavior, which is often the first primary screen.

## Recommended default setup

| Setting                   | Recommended value                                               |
| ------------------------- | --------------------------------------------------------------- |
| Empty state title         | Your profile                                                    |
| Empty state description   | Explain landing screen and notifications                        |
| Navigation                | Last item or `More`                                             |
| Primary screens available | `Home`, `My Queue`, and any role-specific hubs users truly need |

## Testing checklist

* [ ] Profile appears in a predictable navigation location after publish
* [ ] The expected primary screens appear in the landing-screen picker, proving navigation is configured correctly
* [ ] Selecting a landing screen and tapping `Save preferences` persists after reload
* [ ] In-app and email toggles save correctly rather than only changing visually
* [ ] Logout returns the user to the correct signed-out experience
* [ ] `View as user` confirms the right choices for each persona
* [ ] Public-app testing is interpreted correctly, knowing prefs are auth-only

## Troubleshooting

| Symptom                                    | Likely cause                                                      | What to check                                                        |
| ------------------------------------------ | ----------------------------------------------------------------- | -------------------------------------------------------------------- |
| Landing list is empty                      | No screens are marked primary                                     | Update `Edit Navigation` so at least one candidate screen is primary |
| User saves prefs but still lands elsewhere | The chosen screen is hidden or unavailable to that user           | Recheck screen visibility and persona-specific access                |
| Preference changes disappear               | User did not tap `Save preferences`, or prefs API did not persist | Re-test the full save cycle in an authenticated session              |
| Logout is missing or broken                | Auth flow or private-app setup is incomplete                      | Validate the app’s auth host and signed-out redirect                 |
| Profile looks inactive in a public app     | Prefs API is auth-only                                            | Test with a real signed-in end user or `View as user`                |

## Best practices

* Add Profile to every private app.
* Keep the landing-screen choices small and meaningful instead of exposing every possible primary screen.
* Mention in onboarding or Home copy that users can change their landing screen in Profile.