# Welcome to NotionApps
NotionApps turns Notion databases into secure, shareable apps — lists, forms, login, branding, and a published link — without giving users your Notion workspace.
## Build your first app (start here)
Do not bounce across Basics / Customize / Guides yet. Follow this sequence:
1. [Connect Notion](https://docs.notionapps.com/get-started/connect-notion)
2. [Create an app](https://docs.notionapps.com/get-started/create-an-app)
3. [Add List and Details](https://docs.notionapps.com/get-started/add-list-and-details)
4. [Publish and share](https://docs.notionapps.com/get-started/publish-and-share)
5. [Make it private](https://docs.notionapps.com/get-started/make-it-private) (optional)
[Open Get started](https://docs.notionapps.com/get-started)
## Builder map
| Builder rail | Docs |
| ------------ | --------------------------------------------------------------------- |
| Screens | [Screens & components](https://docs.notionapps.com/customize-app) |
| Data | [Settings → Data](https://docs.notionapps.com/settings/data) |
| Users | [Users](https://docs.notionapps.com/users) |
| Automate | [Automation](https://docs.notionapps.com/automation) |
| Settings | [Settings](https://docs.notionapps.com/settings) |
| Integrations | [Integrations](https://docs.notionapps.com/integrations/introduction) |
Full map: [Builder](https://docs.notionapps.com/builder).
## What you can build
* Client and member portals — [Use Cases](https://docs.notionapps.com/use-cases)
* Internal tools and request trackers
* Field apps with photos and signatures
* Approval and operations apps (with Automation)
## Plans & help
* [Plans and entitlements](https://docs.notionapps.com/plans-and-entitlements)
* [Troubleshooting](https://docs.notionapps.com/frequently-asked-questions)
* [Community](https://community.notionapps.com)
* [Release Notes](https://docs.notionapps.com/release-notes)
# Get started
Build your first NotionApps app in under an hour. Follow these steps **in order** — this is the progressive path (Connect → First list → Publish → Private → later Automation).
Sidebar feel long? Start with [How the docs are organized](https://docs.notionapps.com/get-started/how-the-docs-are-organized) (maker path vs secondary sections).
## First-app checklist
1. Connect Notion — authorize the workspace that holds your database
2. Create an app — name it and link a database
3. Add List and Details screens — the core read experience
4. Publish and share — give users a link
5. Make it private — optional login and user restriction
## After your first publish
| Next job | Go here |
| ---------------------------- | ---------------------------------------------------------------------------- |
| Learn the builder rail | [Builder](https://docs.notionapps.com/builder) |
| Brand + URI | [Settings](https://docs.notionapps.com/settings) |
| Custom domain / sharing | [Publish & share](https://docs.notionapps.com/publish-and-share) |
| Forms, Board, Grid, Calendar | [Screens & components](https://docs.notionapps.com/customize-app) |
| Private personalization | [Users](https://docs.notionapps.com/users) |
| Workflows / approvals | [Automation](https://docs.notionapps.com/automation) |
| What your plan unlocks | [Plans and entitlements](https://docs.notionapps.com/plans-and-entitlements) |
## Tip
Stay on **one database** for your first app. Multi-database apps and Automation are easier after you have published a simple list + details flow.
# How the docs are organized
The sidebar follows a **maker path** first, then learning/support sections, then Release Notes.
## Maker path (build an app)
Follow these in order for day-to-day building:
1. [Get started](https://docs.notionapps.com/get-started) — connect Notion, first list, publish, optional private
2. [Builder](https://docs.notionapps.com/builder) — left-rail map (Screens, Databases, Users, Settings, Automation)
3. [Screens & components](https://docs.notionapps.com/screens-and-components) — layouts and field components
4. [Databases](https://docs.notionapps.com/databases) — linked DBs, reload, sync
5. [Users](https://docs.notionapps.com/users) — public/private, roles, View as
6. [Settings](https://docs.notionapps.com/settings) — brand, comments, data, advanced
7. [Publish & share](https://docs.notionapps.com/publish-and-share) — link, domain, sharing
8. [Automation](https://docs.notionapps.com/automation) — when you are ready for workflows
9. [Integrations](https://docs.notionapps.com/integrations) — Slack and other connections
10. [Plans and entitlements](https://docs.notionapps.com/plans-and-entitlements) — what each plan unlocks
11. [Workspace & account](https://docs.notionapps.com/workspace-and-account) — billing, collaborators, reload
## Guides & help
[Guides & help](https://docs.notionapps.com/guides-and-help) is the hub for support extras. [Hire an expert](https://docs.notionapps.com/hire-an-expert) lives under it.
Nearby in the sidebar (after the maker path):
| Need | Section |
| -------------------- | -------------------------------------------------------------- |
| Step-by-step recipes | [How-to guides](https://docs.notionapps.com/how-to-guides) |
| Errors / FAQs | [Troubleshooting](https://docs.notionapps.com/troubleshooting) |
| End-to-end examples | [Use Cases](https://docs.notionapps.com/use-cases) |
| Watch someone build | [Video Tutorials](https://docs.notionapps.com/video-tutorials) |
| Older / legacy docs | [Archive](https://docs.notionapps.com/archive) |
## Changelogs
* [Release Notes](https://docs.notionapps.com/release-notes) — stays near the end so updates are easy to find
Nothing above is hidden or removed — only reordered for a clearer maker path.
# Connect Notion
NotionApps reads and writes the Notion databases you authorize. Connecting a workspace is the first step.
## What you need
* A Notion account with access to the database you want to app-ify
* Permission to install the NotionApps integration on that workspace
## Steps
1. Sign in to NotionApps and open **My Apps** (or create an account if you are new).
2. Start creating an app, or open an existing app and go to **Databases** / connect flow when prompted.
3. Choose the Notion workspace, then grant access to the pages/databases NotionApps should use.
4. Confirm the database appears as a linked database in the builder.
## After you connect
* Use **Sync from Notion** / **Reload Data** when you add properties in Notion.
* If a database is missing, re-open Notion sharing for the integration and share the parent page that contains the database.
## Deep dive
Full detail: [Connect Notion](https://docs.notionapps.com/basics/connect-notion)
## Next
[Create an app](https://docs.notionapps.com/get-started/create-an-app)
# Create an app
Create an app shell, pick a URL, and link the Notion database you connected.
## Steps
1. From **My Apps**, choose **Create app** (or the equivalent new-app action).
2. Enter an app name and confirm the public URI (for example `yourapp.notionapps.com`).
3. Select the Notion database that will power your first screens.
4. Open the **builder** — you should see Screens, Data, Users, and Settings in the left rail.
## Good first choices
| Choice | Recommendation |
| ---------- | ------------------------------------------------------------------------- |
| Database | One primary table with a title property and a few fields users care about |
| Access | Leave **Public** until you finish List + Details and publish once |
| Navigation | Default tabs are fine; tidy icons later |
## Deep dive
[Create an app](https://docs.notionapps.com/basics/create-an-app)
## Next
[Add List and Details screens](https://docs.notionapps.com/get-started/add-list-and-details)
# Add List and Details
Most apps start with a **List (View Items)** screen and a **Details (View One Item)** screen so users can browse records and open one item.
## Steps
1. In the builder, open **Screens**.
2. Click **+ New Screen** and add **List (View Items)** for your database.
3. In **Content**, map **Title** (and optional description / color tag) to Notion properties.
4. Add **Details (View One Item)** for the same database.
5. On the List screen, set the open action to go to Details (Open Item / navigate to details).
6. On Details, add **View** components for the fields users should read (Status, Owner, dates, etc.).
7. Open **Edit Navigation** and keep both screens reachable (or Details hidden and opened only from the list).
## Preview
Use the phone/desktop preview in the center of the builder. Tap a row and confirm Details opens with the right fields.
## Learn more
* [List (View Items)](https://docs.notionapps.com/customize-app/types-of-screens/list-view-items)
* [Details (View One Item)](https://docs.notionapps.com/customize-app/types-of-screens/details-view-one-item)
* [Types of Screens](https://docs.notionapps.com/customize-app/types-of-screens)
## Next
[Publish and share](https://docs.notionapps.com/get-started/publish-and-share)
# Publish and share
Publishing makes your latest builder configuration available on the app URL. Sharing that URL is how users open the app.
## Steps
1. Click **Publish** in the builder top bar.
2. Wait for the publish confirmation.
3. Open the app URI (shown near the app name) in a private/incognito window to verify what end users see.
4. Share the link with your team or customers.
## Checklist before you share widely
* [ ] List shows the rows you expect
* [ ] Details opens from a list row
* [ ] Branding (name, color, icon) looks acceptable
* [ ] You tested on mobile width once
## Deep dive
* [Publish](https://docs.notionapps.com/basics/share-app/publish)
* [Share App Link](https://docs.notionapps.com/basics/share-app/share-app-link)
* [Custom Domain](https://docs.notionapps.com/customize-app/custom-domain) (paid)
## Next
[Make it private](https://docs.notionapps.com/get-started/make-it-private) (optional)
# Make it private
When the app should not be open to anyone with the link, switch to a **Private** app, choose a login method, and (usually) restrict which Notion rows each user can see.
## Steps
1. Open **Users** in the builder rail.
2. Set the app to **Private** (see [Private apps](https://docs.notionapps.com/users/private-apps)).
3. Create or link a **Users** database and add at least one test user.
4. Choose a login method that is available today (email OTP and email+password are common; Google Login is available via Integrations).
5. Configure [Data Restriction](https://docs.notionapps.com/users/data-restriction) / personalization so users only see their rows.
6. **Publish** again, then open the app while signed out — you should hit login.
## Auth overview
See the full matrix: [Auth and access](https://docs.notionapps.com/users/auth-and-access)
## Related
* [App Users](https://docs.notionapps.com/users/app-users)
* [Sign up](https://docs.notionapps.com/users/sign-up)
* [Google Login](https://docs.notionapps.com/integrations/google-login)
## What’s next after your first private app
* Add a **Form (Add Item)** or **Form (Update One Item)**
* Try [Board layouts](https://docs.notionapps.com/guides/board-list-view)
* Explore [Automation](https://docs.notionapps.com/automation) if you need approvals or routing
# Builder
Map of the NotionApps **builder left rail**. Use after [Get started](https://docs.notionapps.com/get-started).
## Rail → docs
| Rail | Opens in product | Docs |
| ---------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| **Screens** | Screen list, layouts, navigation, components | Screens → [Screens & components](https://docs.notionapps.com/screens-and-components) |
| **Databases** | Linked Notion databases, reload, recovery entry points | Databases → [Databases section](https://docs.notionapps.com/databases) |
| **Users** | Public/Private, App Users, Data Restriction, signup | Users → [Users section](https://docs.notionapps.com/users) |
| **Settings** | General, Appearance, Comments, Version History, Data, Advanced | Settings → [Settings](https://docs.notionapps.com/settings) |
| **Integrations** | Google Login (only shipping integration today) | [Integrations](https://docs.notionapps.com/integrations/integrations) |
| **Automation** | One Automation entry when entitled (hub inside — not three rail icons) | Automate → [Automation](https://docs.notionapps.com/automation) |
Help lives in the **rail footer** (docs, community, tour, zoom) — not a main rail destination.
## Recommended maker order
1. Screens — List + Details (+ Create Form when needed)
2. Databases — confirm links + reload after Notion changes
3. Settings — name, URI, theme
4. [Publish & share](https://docs.notionapps.com/publish-and-share)
5. Users — when the app must be Private / personalized
6. Automation — only after the data path works
7. [Plans and entitlements](https://docs.notionapps.com/plans-and-entitlements) — when a control is missing
## Also useful
* [Find your way around the builder nav rail](https://docs.notionapps.com/how-to-guides/find-your-way-around-the-builder-nav-rail)
* [How-to guides](https://docs.notionapps.com/how-to-guides)
* [Troubleshooting](https://docs.notionapps.com/troubleshooting)
# Screens
Configure what end users see and tap.
## Start here
1. [Add New Screen](https://docs.notionapps.com/screens-and-components/add-new-screen)
2. [Types of Screens](https://docs.notionapps.com/screens-and-components/types-of-screens)
3. [View Types](https://docs.notionapps.com/screens-and-components/customize-a-screen/view-types-list-grid-calendar-board) — List / Grid / Calendar / Board
4. [Type of Components](https://docs.notionapps.com/screens-and-components/type-of-components)
## Layouts
* [Grid view](https://docs.notionapps.com/screens-and-components/grid-view)
* [Calendar view](https://docs.notionapps.com/screens-and-components/calendar-view)
* [Board List View](https://docs.notionapps.com/how-to-guides/board-list-view)
## Navigation
* [App Navigation](https://docs.notionapps.com/screens-and-components/app-navigation)
* [Navigation Groups](https://docs.notionapps.com/screens-and-components/navigation-groups)
Full section: [Screens & components](https://docs.notionapps.com/screens-and-components)
# Databases
Manage linked Notion databases and keep schema/data fresh.
→ [**Databases section**](https://docs.notionapps.com/databases) (full docs)
Quick links:
* [Manage linked databases](https://docs.notionapps.com/databases/manage-linked-databases)
* [Reload and sync](https://docs.notionapps.com/databases/reload-and-sync)
* [Settings → Data](https://docs.notionapps.com/settings/data)
# Users
Privacy, login, App Users, and row-level personalization.
1. [Auth and access](https://docs.notionapps.com/users/auth-and-access)
2. [Private apps](https://docs.notionapps.com/users/private-apps)
3. [App Users](https://docs.notionapps.com/users/app-users)
4. [Data Restriction](https://docs.notionapps.com/users/data-restriction)
5. [Roles and navigation](https://docs.notionapps.com/users/roles-and-navigation)
6. [View as any user](https://docs.notionapps.com/users/view-as-any-user)
Full section: [Users](https://docs.notionapps.com/users)
# Settings
App-wide controls (not a single screen).
| Pane | Docs |
| --------------- | ---------------------------------------------------------------------------------- |
| General | [Settings → General](https://docs.notionapps.com/settings/general) |
| Appearance | [Settings → Appearance](https://docs.notionapps.com/settings/appearance) |
| Comments | [Settings → Comments](https://docs.notionapps.com/settings/comments) |
| Version History | [Settings → Version History](https://docs.notionapps.com/settings/version-history) |
| Data | [Settings → Data](https://docs.notionapps.com/settings/data) |
| Advanced | [Settings → Advanced](https://docs.notionapps.com/settings/advanced) |
Hub: [Settings](https://docs.notionapps.com/settings)
# Automate
When entitled, the rail shows **one Automation entry**. Inside the hub you work across Home, Recipes, Workflows, Messaging, Route map, Debugging, and Access — not three separate rail icons.
→ [Automation hub map](https://docs.notionapps.com/automation/automation-hub-map)
Canonical process path:
1. [Automation Overview](https://docs.notionapps.com/automation/automation-overview)
2. [Start From a Wizard](https://docs.notionapps.com/automation/start-from-a-wizard)
3. [Native Automation screens index](https://docs.notionapps.com/automation/native-automation-screens-index)
4. [Plans and entitlements](https://docs.notionapps.com/plans-and-entitlements) if screens are missing
# Screens & components overview
Builder **Screens** rail documentation (formerly “Customize App” in the sidebar label).
## Core screen types
* [Types of Screens](https://docs.notionapps.com/customize-app/types-of-screens) — List, Details, Forms, Content, chrome, Automation screens
* [Add New Screen](https://docs.notionapps.com/customize-app/add-new-screen)
* [Customize a screen](https://docs.notionapps.com/customize-app/customize-a-screen)
* [View Types (List / Grid / Calendar / Board)](https://docs.notionapps.com/customize-app/customize-a-screen/view-types-list-grid-calendar)
## Layout deep dives
* [Grid view](https://docs.notionapps.com/customize-app/grid-view)
* [Calendar view](https://docs.notionapps.com/customize-app/calendar-view)
* [Board List View](https://docs.notionapps.com/guides/board-list-view)
## Navigation & chrome
* [App Navigation](https://docs.notionapps.com/customize-app/app-navigation)
* [Navigation Groups](https://docs.notionapps.com/customize-app/navigation-groups)
* [Desktop View](https://docs.notionapps.com/customize-app/desktop-view)
## Components
* [Type of Components](https://docs.notionapps.com/customize-app/type-of-components)
* [Address](https://docs.notionapps.com/customize-app/type-of-components/address) · [File upload](https://docs.notionapps.com/customize-app/type-of-components/file-upload) · [User field](https://docs.notionapps.com/customize-app/type-of-components/user-field) · [Comments](https://docs.notionapps.com/customize-app/type-of-components/comments)
## Also in this area
Custom domain, relations, formulas, barcode scanner, form submit redirection — see the sidebar under **Screens & components**.
Map back to the builder: [Builder](https://docs.notionapps.com/builder).
# App Navigation
NotionApps allows you to configure the navigation in your app with two types of navigation: *bottom tabs* and *side drawer*. By default, the app builder automatically adds a newly created screen to the bottom tab, but you can move the screen between the bottom tab and drawer as needed. Here's how to configure the navigation in your app:
1. On the home page, click on the app you want to customize. This will open your app in the app builder.
2. Click on the "Edit Navigation" button in the bottom-right corner of the app builder to view the navigation and icon/name of your screens.
3. To move a screen between the bottom tab and drawer, simply click on the screen and drag it to the desired location. You can also reorder screens using the drag (✥) icon.
{% hint style="info" %}
We suggest a maximum of 5 screens in the bottom tabs for the best experience.
{% endhint %}
4. To change the name or icon of a screen, click on the screen and then edit the desired properties.
5. Once you're done, you can go back to editing the screen by clicking on the "Edit Screen" button.
{% hint style="info" %}
We recommend putting primary screens or actions in the bottom tab and secondary screens or actions, like "Profile" or "About" screens, in the drawer.
This helps users easily access the most important screens and actions while keeping less frequently used screens and actions hidden.
{% endhint %}
By following these simple steps, you can easily configure the navigation in your NotionApp. Whether you want to reorder screen positions, change the name or icon of a screen, or configure the side drawer, the app builder makes it easy to create a user-friendly and intuitive app navigation.
# Navigation Groups
Navigation groups help you organize screens inside the side navigation of your app. You can use groups to keep your navigation clean when your app has many screens.
For example, you can create an "Archive" group and place older screens like "2023 Results", "2022 Results", or "Past Squads" inside it.
Follow these steps to create and use navigation groups:
1. Open your app in the app builder.
2. Click on the "Edit Navigation" button in the bottom-right corner of the app builder. This will open the navigation settings for your app.
3. Make sure the screens you want to group are in the side navigation.
If a screen is currently in the bottom tabs, drag it into the side navigation section first.
{% hint style="info" %}
Navigation groups are only available for screens in side navigation. Screens in bottom tabs cannot be placed inside groups.
{% endhint %}
4. Click the "Add group" button in the side navigation section.
A new group will be added to your side navigation.
5. Rename the group by editing the group name.
For example, you can name the group "Archive", "Reports", "Admin", or anything else that helps organize your app.
6. Add screens to the group.
Click on a screen in the side navigation, then use the "Group" dropdown to select the group where the screen should appear.
7. Repeat this for any other screens you want to place inside the group.
The grouped screens will appear under the group in the side navigation preview.
8. To remove a screen from a group, click on the screen and set the "Group" dropdown back to "No group".
9. To reorder groups, use the "Move up" and "Move down" buttons on the group.
10. To delete a group, click the "Delete group" button.
{% hint style="info" %}
Deleting a group does not delete the screens inside it. The screens will stay in the side navigation and will no longer be grouped.
{% endhint %}
11. Preview your app.
In the app preview, group names appear as collapsible rows. Users can click the group name or caret to expand or collapse the screens inside it.
12. Once you're done, publish your app to make the navigation group changes live for your users.
{% hint style="success" %}
Changes are automatically saved in the app builder, but they only show up on your app link after publishing the app.
{% endhint %}
Navigation groups are useful for keeping less frequently used screens tucked away while still making them easy to access when needed.
# App Icon, Colour, URL
NotionApps allows you to customize your app's icon, colour, and URL to create a unique look and feel for your app. You can customize these attributes by following these steps:
1. Open your app in the app builder.
2. Click on the "Settings" button in the left side panel of the app builder.
3. To customize the app icon, scroll to the "App Icon" section inside the settings. You can choose an icon from our library or upload a custom icon from your system.
4. To customize the app colour, scroll to the "App Color Theme" section. You can choose from our pre-defined colour themes.
5. To customize your app's URL, scroll to the "URL" section. Your app's URL can only contain letters, numbers, and hyphens. If the URL you want is already taken, you'll need to choose a different URL. Once you've chosen your URL, you will need to publish the app for the app to be available at the desired URL.
{% hint style="info" %}
You can also customize the app's name and description.
{% endhint %}
By following these simple steps, you can easily customize your NotionApp's icon, colour, and URL. Whether you want to create a unique look and feel for your app or make it easier for users to identify your brand, the app builder makes it easy to customize your app to your liking.
# Custom Domain
You can link your own custom domain to the apps. This means that the app will be available on *app.mydomain.com* instead of *app.notionapps.com,* making it easier to promote the app with your branding when sharing it with others.
{% hint style="info" %}
Subdomains under a root domain count as a single custom domain. For example, blog.mydomain.com and sales.mydomain.com will be counted as one custom domain.
However, if you have two apps, one linked with mydomain.com and the other with myseconddomain.com, these will be counted as two custom domains.
{% endhint %}
{% embed url="" %}
### Update your DNS Settings
Below you can find the DNS settings that need to be included on your domain registrar's (GoDaddy, Namecheap, Google Domains, etc) or DNS provider's (Cloudflare, Netlify, etc) website.
### Root domain records
For a root domain like `example.com` you'll need to add the following records:
| Type | Name | Value |
| ----- | ---- | -------------------- |
| A | @ | 76.76.21.21 |
| CNAME | www | cname.notionapps.com |
{% hint style="warning" %}
Make sure to remove any old A records or AAAA records for your root domain or old CNAME entries for www in your DNS settings if your provider does not do this automatically.
{% endhint %}
### Subdomain records
For a subdomain like `blog.example.com` add this record:
| Type | Name | Value |
| ----- | ---------------- | -------------------- |
| CNAME | (your subdomain) | cname.notionapps.com |
{% hint style="warning" %}
Make sure to remove any old A records for your subdomain or CNAME entries for the subdomain in your DNS settings if your provider does not do this automatically.
{% endhint %}
### Adding your custom domain to your app
To add a domain to your app,
1. Open the NotionApps app builder
2. Go to App Settings
3. Add your custom domain to the input in the *Custom Domain* section
After entering your own domain address in the popup, if you haven’t already done so, you'll then need to make some changes to the DNS settings through your hosting provider.
You would need to change your DNS records through your domain registrar's (GoDaddy, Namecheap, Google Domains, etc) or DNS provider's (Cloudflare, Netlify, etc) website. For specific instructions, view the content inside the blocks above.
{% hint style="info" %}
**If you run into issues, please make sure that you have:**
* Added new DNS records to your domain provider
* Removed old DNS records
* Waited up to 24 hours for new settings to propagate
{% endhint %}
## Troubleshooting
***Problem***
My custom domain shows an empty screen and I use CloudFlare as my DNS Provider/Proxy.
***Solution***
When Cloudflare proxy is on your site may show an error `err_too_many_redirects`.
This issue occurs when your Cloudflare SSL/TLS configuration is set to "Flexible". This will have Cloudflare send requests to NotionApps over HTTP and in response, NotionApps will send data back over HTTPS.
To keep all our connections secure you must request Cloudflare to only send requests over HTTPS. To fix this issue, the "SSL/TLS" option in Cloudflare needs to be set to "Full (strict)".
***Problem***
My custom domain is configured and it's been some time but the browser still shows an SSL error.
***Solution***
NotionApps uses Vercel to provide you with custom domains. If you use another service that may be using Vercel as their domain provider, you can see such as SSL error.
To resolve this, please reach out to us at and we will help you resolve this quickly.
# Buy Additional Custom Domains
## **How to purchase additional custom domains:**
1. **Subscribe to a paid NotionApps plan:** This feature is not available on the FREE plan. Upgrade to a paid plan that best suits your needs. Go to the [Pricing](https://www.notionapps.com/pricing) page to upgrade.
2. **Access your account settings:** On the NotionApps [homepage](https://www.notionapps.com/home), click on **Settings** in the side navigation bar.
3. **Locate the "Buy More" option:** Under the **Usage** section, click the **"Buy more usage"** button.
4. **Manage your plan through Stripe:** You'll be redirected to a secure Stripe customer portal. Click **"Update Plan"** to manage your subscriptions.
5. **Add "Extra Custom Domain" add-on:** Look for the new option **"Extra Custom Domain"** under available add-ons.
6. **Choose the quantity and confirm:** Select the number of additional custom domains you want to purchase and confirm your selection.
## **Important notes:**
* This feature is not currently available on free plans.
* For custom solutions or bulk purchases, please contact NotionApps support at `help@notionapps.com`.
* Remember to update your DNS settings with the provided information after purchasing your additional domains.
## **Additional resources:**
* Learn more about custom domains in our documentation:
* Watch a video tutorial on configuring custom domains:
# Add New Screen
## Add New Screen
Adding a new screen to your NotionApp is a simple process that allows you to customize the look and functionality of your app. Follow these steps to add a new screen to your app:
1. Open your app in the app builder.
2. Click on the "+ New Screen" button in the bottom-right corner of the app builder. This will open a popup that allows you to add a new screen to your app.
3. Select the Notion database whose items you want to view, update, or add from the drop-down menu.
4. Select the type of screen you want to add. There are four types of screens available: List (View Items), Details (View One Item), List (Update Items), Form (Update Item), and Form (Add Item). Each type of screen has different functionality, so choose the one that best fits your needs.
5. Press the "Done" button to add the screen to your app.
After adding the screen, you can customize its appearance and functionality. You can customize the look of the screen by changing its row configuration, title, and icon. You can also filter and sort the screen items to display the data in the way that makes the most sense for your app.
#### Other Screen Actions
You can delete or duplicate a screen on NotionApps using the buttons provided right next to the screen name.
{% hint style="info" %}
The option to delete or duplicate a screen is only available on the top-level screens in the bottom tabs or the side drawer.
{% endhint %}
### When this app needs automation
Use the normal instructions on this page when users only need to view, add, or update data. Use automation when the app needs to do something after that data changes, such as submit for approval, notify a reviewer, route work to a queue, start a conversation, update workflow status, or show a recoverable failure.
Good next steps:
* Automation Overview explains the full maker journey.
* Start From a Wizard is the safest way to create a guided workflow.
* Create your first approval workflow walks through a complete approval setup.
* Native Automation Screens explains Decision, Work Queue, Notification Center, Conversation, Workflow Status, Exception Resolution, Automation Launcher, Linked App Exchange, and Operator Console.
# Types of Screens
Screens are the pages your app users open to view data, update records, submit forms, make decisions, follow workflow status, send messages, recover workflow problems, or act on work routed by automation. A good screen type choice keeps the app simple: users should immediately understand what they are looking at, what they can do, and what result to expect after they act.
NotionApps screen types fall into these families:
* **Data screens** show or edit records from connected Notion databases. These are the standard screens used for lists, detail pages, update forms, and add-item forms.
* **Automation screens** show work created by workflows, approvals, messages, notifications, exceptions, launch actions, linked app exchanges, and operational runtime data.
* **Everyday chrome screens** give users Home, Search, and Profile — always-on app-shell utilities that do not require Automation entitlements.
* **Queue & activity screens** give users My Queue and Activity — personal “needs me” and history feeds that require Workflow, Messaging, or Approval Management.
**Data screen types**
Use data screens when the user's main job is to view, create, or update Notion-backed records. Each leaf guide below includes a complete builder options reference (What it does / How to use / Why) and annotated builder screenshots.
| Screen type | Use it when | Guide |
| ----------------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| List (View Items) | Users need to browse many records without editing them directly. | [List (View Items)](https://docs.notionapps.com/customize-app/types-of-screens/list-view-items) |
| Details (View One Item) | Users need a focused read-only page for one record. | [Details (View One Item)](https://docs.notionapps.com/customize-app/types-of-screens/details-view-one-item) |
| List (Update Items) | Users need to review and update multiple records from one list. | [List (Update Items)](https://docs.notionapps.com/customize-app/types-of-screens/update-items-form) |
| Form (Update One Item) | Users need to edit one existing record through a guided form. | [Form (Update One Item)](https://docs.notionapps.com/customize-app/types-of-screens/form-update-one-item) |
| Form (Add Item) | Users need to create a new record from the app. | [Form (Add Item)](https://docs.notionapps.com/customize-app/types-of-screens/add-new-item-form) |
| Content | Users need a branded landing, help, or consent page that is not tied to a Notion database. | [Content](https://docs.notionapps.com/customize-app/types-of-screens/content) |
Related maker how-tos for data screens: [Prefill Create Forms from a URL](https://docs.notionapps.com/guides/prefill-create-forms-from-a-url), [Validate Email and Phone on Form Fields](https://docs.notionapps.com/guides/validate-email-and-phone-on-form-fields), [Filter List Screens by Logged-in User Properties](https://docs.notionapps.com/guides/filter-list-screens-by-logged-in-user-properties), [Per-Screen Public Access](https://docs.notionapps.com/guides/per-screen-public-access).
**Automation screen types**
Use automation screens when the user's main job is to act on work created by a workflow, understand where work is in a process, respond to a message, recover a failure, launch an operation, or hand work to another app or destination.
| Automation screen | Use it when |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| Work Queue | A focused inbox where users claim, complete, or escalate workflow-created work. |
| Decision | Human checkpoints where a reviewer chooses Approve, Reject, Request changes, or a similar business decision. |
| Workflow Status | Showing where workflow runs are in the process, including waits, retries, completed steps, and outcomes. |
| Conversation | Workflow-aware message threads, comments, replies, and support exchanges tied to a record, route, or conversation. |
| Exception Resolution | Recovering failed workflow steps, missing data, blocked routes, retries, and manual fixes. |
| Notification Center | Persistent alerts, announcements, reminders, unread notices, and acknowledgements. |
| Automation Launcher | Controlled manual starts, service requests, operator actions, and launch buttons for workflows. |
| Linked App Exchange | Requests, messages, payloads, acknowledgements, and handoffs exchanged between linked NotionApps applications. |
| Operator Console | A high-level dashboard for app owners and operators to monitor runs, queue depth, failures, messages, and audit activity. |
Guides live under [Native Automation And Operational Screen Guides](https://docs.notionapps.com/customize-app/types-of-screens/native-automation-and-operational-screen-guides).
**Everyday chrome screen types**
Use Everyday chrome when users need always-on app shell screens that do **not** require Automation entitlements.
| Everyday chrome screen | Use it when |
| ---------------------- | ----------------------------------------------------------------------- |
| Home | Users need a daily landing surface with next actions and a primary CTA. |
| Search | Users need cross-database keyword search from one place. |
| Profile | Users need landing-screen and notification preferences. |
Guides live under [Everyday Chrome Screens](https://docs.notionapps.com/customize-app/types-of-screens/everyday-chrome-screens).
**Queue & activity screen types**
Use Queue & activity when users need personal feeds backed by automation activity. These cards appear only when Workflow, Messaging, or Approval Management is enabled. Keep this family separate from Everyday chrome when you plan entitlements and navigation.
| Queue & activity screen | Use it when |
| ----------------------- | --------------------------------------------------------- |
| My Queue | Users need a personal inbox of work and notifications. |
| Activity | Users need a timeline of submits, decisions, and updates. |
Guides live under [Queue & Activity Screens](https://docs.notionapps.com/customize-app/types-of-screens/queue-and-activity-screens).
**How to choose the right screen**
1. If the user is browsing or editing Notion records, use a data screen.
2. If the user is claiming or completing routed work, use Work Queue.
3. If the user is approving, rejecting, or requesting changes, use Decision.
4. If the user needs to see workflow progress, use Workflow Status.
5. If the user needs to discuss work in context, use Conversation.
6. If the user needs announcements or reminders, use Notification Center.
7. If the user needs to fix blocked automation, use Exception Resolution.
8. If the user needs to manually start an operation, use Automation Launcher.
9. If work moves between apps, use Linked App Exchange.
10. If an owner needs operational health, use Operator Console.
11. If the user needs a Home hub, Search, or Profile prefs, use an Everyday chrome screen.
12. If the user needs a personal My Queue or Activity feed, use a Queue & activity screen.
Before publishing, run the workflow or message path that should feed the screen. The screen is ready when a non-technical user can open it, understand what happened, and take the expected next action without support help.
### Updates in the 9 Aug 2026 release
* **Content Pages** are first-class unbound screens (HTML/CSS, no Notion database). See [Content](https://docs.notionapps.com/customize-app/types-of-screens/content).
* Apps can mix **public** and **private** screens on one URL. See [Build a Mixed Public–Private Portal](https://docs.notionapps.com/guides/build-a-mixed-public-private-portal).
* Automation screens gained multi-sheet Work Queues, Decision writeback/attachments, Conversation file uploads, and Launcher announcements — see the [9 Aug 2026 Release](https://docs.notionapps.com/release-notes/9-aug-2026-release).
# List (View Items)
The **List (View Items)** screen shows many records from a Notion database in one place. It is the main browsing surface for apps: users scan rows, search or filter, and open a details screen when they need more.
{% hint style="info" %}
**Who this guide is for**\
Makers configuring a list of Notion records. This guide explains every List builder option across the **Content**, **Behaviour**, and **Appearance** tabs, including when each control appears.
{% endhint %}
## What the screen is for
### Use List (View Items) when
* Users need to browse many records from one database
* You want search, sorting, grouping, or end-user filters
* Row click should open a **Details** screen
* You may also want an **Add** path into a Create Form
### Do not use it when
* Users only submit new records with no browsing: use **Form (Add Item)**
* Users edit one existing record: use **Form (Update One Item)** or **List (Update Items)**
* Work is claim-and-complete workflow items: use **Work Queue**
* The page is static HTML: use **Content**
## What users see in the live app
* A list, grid, calendar, or board of records (View Type)
* Mapped Title / Description / Caption / Tag / Image fields (depending on layout)
* Optional search, scanner, and in-app filters
* Optional add button when Add New Item is enabled
* Row tap opens the configured Details screen when Open Item On Click is on
## Add List (View Items) in the builder
1. Open **Screens → + New Screen**.
2. Choose the Notion database to list.
3. Under **Data screens**, select **List (View Items)**.
4. Click **Done**.
5. Map Title (required) and other Data fields.
6. On **Behaviour**, point **Go to Screen** at a Details screen.
7. On **Appearance**, pick List / Grid / Calendar / Board.
8. Publish and test on phone and desktop.
## Complete Builder Options Reference
List configuration uses three inspector tabs: **Content**, **Behaviour**, and **Appearance**. Per-field styling and validation are edited in the field inspector after you open a Details/Form field — not on these list tabs.
### Content tab
#### Data
**Title**
**What it does:**\
Sets the primary property shown as each row’s title. Required for a usable list.
**How to use it:**\
Pick the field users recognize first (name, request summary, ticket title). Avoid IDs unless users search by ID.
**Why / recommended default:**\
Title is the scan target. A common mistake is mapping a weak or empty property, which makes every row look identical.
**Description / Caption**
**What it does:**\
Optional secondary and tertiary text under the title. Hidden in compact List layouts and unavailable in Calendar mode.
**How to use it:**\
Use Description for status or owner; Caption for dates or short metadata. Keep both short for mobile.
**Why / recommended default:**\
Leave blank until the title alone is not enough. Overloading description text makes dense lists hard to scan.
**Color Tag**
**What it does:**\
Maps a select/status-style property to a colored tag on each row, with optional per-option colors.
**How to use it:**\
Point it at Status or Priority. Set colors that match your app theme.
**Why / recommended default:**\
Use for one high-signal status field. A common mistake is tagging a field with too many options, which becomes noisy.
**Image**
**What it does:**\
Shows an image property on each row (List/Grid styles vary).
**How to use it:**\
Map a file/image property. On Appearance, tune Image Style / Fill / Grid Image Style.
**Why / recommended default:**\
Only enable when images add recognition value. Empty image slots waste space.
**Date (Calendar only)**
**What it does:**\
When View Type is Calendar, Date replaces Description/Caption/Tag/Image and places items on the calendar.
**How to use it:**\
Map the date property that should position events. Pair with Title only.
**Why / recommended default:**\
Required for Calendar to be useful. Wrong date fields scatter items incorrectly.
#### Filtering
**Filter rows / + Add Filtering**
**What it does:**\
Maker-defined filters that permanently limit which rows appear on this screen (separate from Data Restriction and In-App Filtering).
**How to use it:**\
Add conditions that define this list’s job (for example Status is Open). Use AND/OR as needed.
**Why / recommended default:**\
Prefer a clear fixed filter over teaching users to filter everything manually. A common mistake is duplicating Data Restriction here.
#### Logged-in user property filters
**Allow logged-in user property filters**
**What it does:**\
Lets filters compare list properties to the signed-in user’s Users-sheet properties (for example Owner equals Me).
**How to use it:**\
Enable when each user should see “my” rows. Requires a linked Users sheet and matching properties. May be plan-gated.
**Why / recommended default:**\
Excellent for private portals. Do not enable for public guest lists — guests have no user profile.
#### Grouping
**Group By / Order / + Add Grouping**
**What it does:**\
Groups rows by a property (feature/beta may apply). Hidden for Calendar. Typically one group level.
**How to use it:**\
Group by Status or Category when users triage by buckets. Choose A→Z or Z→A order.
**Why / recommended default:**\
Skip grouping until the list is long enough that buckets help. Grouping empty or unique fields adds clutter.
#### Sorting
**Sort By / Order / + Add Sorting**
**What it does:**\
Default sort for the list. Hidden for Calendar.
**How to use it:**\
Sort by newest date or priority. Add multiple levels only when needed.
**Why / recommended default:**\
Default to newest-first for operational lists. Unsorted lists feel unfinished.
#### In-App Filtering
**Filter Name / Filter Columns / + Add Filter Property**
**What it does:**\
Defines filters end users can change while browsing (distinct from maker Filtering).
**How to use it:**\
Expose 1–3 useful columns (Status, Category, Owner). Name filters clearly.
**Why / recommended default:**\
Use for exploratory browsing. Do not expose every column — mobile filter UIs get heavy.
### Behaviour tab
#### Open Item On Click / Go to Screen
{% hint style="info" %}
On **List (View Items)**, this control is labeled **Open Item On Click**. The annotated screenshot below is taken from the same Behaviour panel position on a List (Update Items) screen, where the twin control is **Go to Update Screen**.
{% endhint %}
**What it does:**\
When on, tapping a row opens the selected Details (or other) screen.
**How to use it:**\
Turn on for browse→details flows. Pick the Details screen for the same database.
**Why / recommended default:**\
On for almost every View List. Leaving it off makes the list feel dead.
#### Add New Item
**Add New Item / Go to Screen**
**What it does:**\
Shows an add affordance that opens a Create Form screen.
**How to use it:**\
Enable when users should create records from this list. Point to the matching Form (Add Item).
**Why / recommended default:**\
On for operational intake lists; off for read-only directories.
#### Allow Search
**Allow Search / Search Helper Text / Show Scanner / Scan Type**
**What it does:**\
Adds a search bar; optional barcode/QR scanner with type Barcode or QR Code.
**How to use it:**\
Enable search for large lists. Set helper text like “Search requests”. Enable scanner only when users scan codes into the same properties.
**Why / recommended default:**\
Search on for lists over \~20 rows. Scanner off unless the workflow is scan-driven.
#### Screen Visibility Logic
**Status / + Add Logic**
**What it does:**\
Controls who can open this screen (restricted vs unrestricted). Logic filters use the Users sheet on private apps.
**How to use it:**\
Keep unrestricted for shared team lists. Add user-sheet logic when only certain roles should see the screen.
**Why / recommended default:**\
Unrestricted unless the screen is role-sensitive. Do not confuse this with Filtering (which rows) or Data Restriction (which rows per user).
#### Data Restriction
**Enabled for this screen**
**What it does:**\
Applies database personalization so each user only sees rows they are allowed to access. Disabled on public apps or when the sheet is not personalized.
**How to use it:**\
Enable for customer/partner portals. Keep off for shared staff desks that should see all open work.
**Why / recommended default:**\
Match the database’s personalization strategy. Enabling without a Users mapping looks like an empty list bug.
### Appearance tab
#### View Type
**View Type**
**What it does:**\
Chooses List, Grid, Calendar, or Board presentation.
**How to use it:**\
List for dense ops queues; Grid for image-heavy catalogs; Calendar for dated work; Board for status columns.
**Why / recommended default:**\
List is the safest default. Calendar requires a Date mapping; Board needs a useful status/select property.
#### Style controls (conditional)
**Grid Column Size / Grid Image Style**
**What it does:**\
Grid density and image crop style when View Type is Grid.
**How to use it:**\
Large for marketing-style cards; Small for denser catalogs.
**Why / recommended default:**\
Large when images matter; Small when titles matter more.
**Image Style / Image Fill**
**What it does:**\
Shape and fit for list/grid images (not Calendar).
**How to use it:**\
Match brand (square vs round). Use Fit for logos; Fill for photos.
**Why / recommended default:**\
Square + Fill is a solid default for photos.
**Default Mode / Allow Mode Change (Calendar)**
**What it does:**\
Calendar starts in Day/Week/Month/Agenda; optional user mode switching.
**How to use it:**\
Month for overview; Week for scheduling teams. Allow Mode Change when users need flexibility.
**Why / recommended default:**\
Month + Allow Mode Change on for most calendar lists.
**View Less Data / Wrap Text / Desktop split view**
**What it does:**\
Compact list density; wrap long text; show list+details side-by-side on wide desktops.
**How to use it:**\
View Less Data for long operational lists. Desktop split view when desktop users triage quickly.
**Why / recommended default:**\
View Less Data on for dense queues; Desktop split view on for staff desktop apps.
### Related setup outside the inspector
#### Edit Navigation
**What it does:**\
Controls nav label, icon, and whether the list appears in guest/signed-in navigation (and Public access on private apps via the screen accordion).
**How to use it:**\
Put primary lists in navigation. Keep secondary lists hidden and open them from buttons.
**Why / recommended default:**\
One primary list in nav beats five competing lists.
#### Field inspector on Details/Form
**What it does:**\
Per-field labels, required, validation, visibility, defaults — configured on Details/Form screens, not on List Data mapping.
**How to use it:**\
After list→details navigation works, polish field-level options on the Details/Form screens.
**Why / recommended default:**\
Do not expect list Data mapping to replace field inspector setup.
## Recommended default setup
| Setting | Recommended value |
| ------------------ | ------------------------------------------------------- |
| Title | Primary human-readable property |
| Open Item On Click | On → Details screen |
| Add New Item | On only if users create from this list |
| Allow Search | On for larger lists |
| View Type | List |
| Filtering | Match the list’s job (e.g. open items only) |
| Data Restriction | On for personalized portals; off for shared staff desks |
## Testing checklist
* [ ] Title mapping is readable on mobile
* [ ] Row click opens the intended Details screen
* [ ] Add button opens the intended Create Form (if enabled)
* [ ] Maker Filtering shows the expected subset
* [ ] In-app filters work for end users
* [ ] Search finds known records
* [ ] Calendar/Board/Grid layouts render with required fields
* [ ] Data Restriction / visibility behave correctly per persona (`View as user`)
## Troubleshooting
| Symptom | Likely cause | What to check |
| ---------------------- | ---------------------------------------------- | ----------------------------------- |
| List is empty | Filtering, Data Restriction, or empty DB | Relax filters; test as another user |
| Row click does nothing | Open Item On Click off or missing Go to Screen | Behaviour tab |
| Calendar empty/wrong | Date not mapped or wrong field | Content → Data → Date |
| Search missing | Allow Search off | Behaviour tab |
| Users see others’ rows | Data Restriction off | Behaviour → Data Restriction |
## Best practices
* One list job per screen (Open requests, Closed archive) instead of one mega-list.
* Always pair View List with a Details destination.
* Keep in-app filters few and meaningful.
* Prefer maker Filtering for permanent scope; In-App Filtering for exploration.
# Details (View One Item)
The **Details (View One Item)** screen shows one Notion record at a time. It is the destination users open from a List row when they need the full record, related fields, and optional edit/delete actions.
{% hint style="info" %}
**Who this guide is for**\
Makers wiring browse→details flows. This guide covers every Details builder option on **Content**, **Behaviour**, and **Appearance**, plus how field-level options work in the field inspector.
{% endhint %}
## What the screen is for
### Use Details when
* Users open one record from a List
* You need a read-focused record page with optional Edit / Delete
* Field order and visibility matter more than bulk browsing
### Do not use it when
* Users primarily create records: use **Form (Add Item)**
* Users edit in place across many rows: use **List (Update Items)** or **Form (Update One Item)**
* The page is marketing/help HTML: use **Content**
## What users see in the live app
* Field components in the order you configure under Logic
* Optional Edit control that opens an Update Form
* Optional Delete (when the screen is not primary and Allow Delete is on)
* Maker Filtering only applies when this Details screen is a primary screen
## Add Details in the builder
1. **Screens → + New Screen** → choose the database → **Details (View One Item)**.
2. Add and order fields under **Content → Logic**.
3. On **Behaviour**, enable **Allow Editing** and point to an Update Form if users should edit.
4. From the List screen, set **Open Item On Click → Go to Screen** to this Details screen.
5. Publish and test list→details navigation.
## Complete Builder Options Reference
### Content tab
#### Logic
**Field / component list**
**What it does:**\
Defines which properties appear and in what order (add, reorder, remove comps).
**How to use it:**\
Add only fields users need. Put identity fields first (title, status), then details, then attachments.
**Why / recommended default:**\
A short, ordered Details page beats dumping every Notion property. Empty Logic shows “Add Logic to edit the screen”.
#### Filtering (primary screens only)
**Filter rows**
**What it does:**\
Limits which records this primary Details screen can show when opened as a standalone primary route.
**How to use it:**\
Usually leave empty when Details is only opened from a List with its own filters. Use when Details is primary and must be scoped.
**Why / recommended default:**\
Off/empty for typical list→details apps. Prefer list Filtering for browse scope.
### Behaviour tab
#### Allow Editing
**Allow Editing / Go to Update Screen**
**What it does:**\
Shows an edit path into a Form (Update One Item) for the same database.
**How to use it:**\
Enable for staff/customer edit flows. Select the Update Form screen.
**Why / recommended default:**\
On when users should change records; off for read-only portals.
#### Allow Delete (non-primary only)
**Allow Delete / Button Text / Ask for confirmation / Delete Confirmation Text**
**What it does:**\
Lets users delete the open record. Available when the Details screen is not the app’s primary screen. Success message is typically hidden for Notion.
**How to use it:**\
Enable only for trusted roles. Keep confirmation on. Use clear button text like “Delete request”.
**Why / recommended default:**\
Off by default. Destructive actions should be rare and confirmed.
#### Screen Visibility Logic (primary)
**Visibility status / + Add Logic**
**What it does:**\
Controls who can open this Details screen when it is primary (Users-sheet logic on private apps).
**How to use it:**\
Restrict when Details is a landing surface for a role. Otherwise leave unrestricted and rely on list navigation.
**Why / recommended default:**\
Unrestricted for standard secondary Details screens.
### Appearance tab
Details Appearance is intentionally empty: field styles live in the field inspector and app theme lives in Settings.
### Field inspector (not screen tabs)
When you select a field in Logic, makers commonly set:
* Label, Helper Text
* Visibility Logic (when the field shows)
* View/style options for read-only display
* For linked edit forms: required, validation, defaults (on the Update Form fields)
**Why / recommended default:**\
Treat Details as layout + navigation; treat the field inspector as copy and visibility polish.
### Related setup outside the inspector
#### List Open Item On Click
Wire the List Behaviour tab to this Details screen or users cannot open records.
#### Edit Navigation
Details is often hidden from navigation and reached only from lists. Mark primary only if users should land here.
## Recommended default setup
| Setting | Recommended value |
| ------------- | ------------------------------------- |
| Logic fields | Title, status, key details, files |
| Allow Editing | On → Update Form (if edits allowed) |
| Allow Delete | Off unless trusted role + non-primary |
| Filtering | Empty for secondary Details |
| Navigation | Usually hidden; open from List |
## Testing checklist
* [ ] List row opens this Details screen with the correct record
* [ ] Field order reads well on mobile
* [ ] Edit opens the Update Form with the same record
* [ ] Delete (if enabled) confirms and removes the Notion page
* [ ] Hidden fields respect visibility logic
* [ ] `View as user` confirms role-appropriate access
## Troubleshooting
| Symptom | Likely cause | What to check |
| -------------------------- | --------------------------------------- | --------------- |
| List does not open Details | List Go to Screen wrong / Open Item off | List Behaviour |
| Blank Details | No Logic comps or wrong record context | Content → Logic |
| Edit missing | Allow Editing off | Behaviour |
| Delete missing | Screen is primary or Allow Delete off | Behaviour |
## Best practices
* Keep Details scannable; push rare fields lower or hide with visibility logic.
* Always pair with List Open Item On Click.
* Prefer Update Form for editing instead of overloading Details.
# List (Update Items)
The **List (Update Items)** screen browses many records like a View List, but row open always targets an **Update Form** instead of a Details “open on click” toggle. Use it when the list’s job is “find a row and edit it.”
{% hint style="info" %}
**Who this guide is for**\
Makers building edit-centric lists. Options largely match **List (View Items)**; this guide highlights Behaviour differences and the shared Content/Appearance controls.
{% endhint %}
## What the screen is for
### Use List (Update Items) when
* Users scan many rows and edit them often
* You want list search/filters plus a direct path to Update Form
* A separate read-only Details page is unnecessary
### Do not use it when
* Users mostly read then sometimes edit: use **List (View Items)** → **Details** → **Update Form**
* Users only create: use **Form (Add Item)**
* Work items are workflow queue items: use **Work Queue**
## What users see in the live app
* Same list presentations as View List (List/Grid/Calendar/Board)
* Row tap opens the configured **Update Form**
* Optional Add New Item, search, in-app filters, maker Filtering, Data Restriction
## Add List (Update Items) in the builder
1. **Screens → + New Screen** → database → **List (Update Items)**.
2. Map Data fields (Title required).
3. On **Behaviour**, set **Go to Update Screen** to the Update Form.
4. Configure Appearance View Type.
5. Publish and test row → edit → save.
## Complete Builder Options Reference
### Content tab
Content matches **List (View Items)**:
#### Data
Title (required), Description, Caption, Color Tag, Image, and Calendar Date — same rules and recommendations as View List.
#### Filtering / Logged-in user property filters / Grouping / Sorting / In-App Filtering
Same controls and guidance as View List. Use maker Filtering for permanent scope; In-App Filtering for end-user exploration; user-property filters for “my rows.”
### Behaviour tab
#### Go to Update Screen
**Go to Update Screen**
**What it does:**\
Always navigates row open to an Update Form (no “Open Item On Click” toggle).
**How to use it:**\
Select the Form (Update One Item) for the same database.
**Why / recommended default:**\
Required for the screen to be useful. Pointing at Details defeats the edit-list purpose.
#### Add New Item / Allow Search / Screen Visibility / Data Restriction
Same as View List:
* **Add New Item** → Create Form when users also create from this list
* **Allow Search** (+ helper text, optional scanner)
* **Screen Visibility Logic** for who can open the list
* **Data Restriction** for personalized row access
### Appearance tab
#### View Type / Style
Same as View List: List, Grid, Calendar, Board, plus conditional image/calendar/compact/split-view controls.
### Not in the current inspector
A legacy “update multiple rows” section exists in code but is **not shown** in the current tabbed inspector. Do not document it as an available maker control.
### Related setup
* Create a matching **Form (Update One Item)** before wiring Go to Update Screen
* Prefer this list when edit is the primary job; prefer View List→Details when reading is primary
## Recommended default setup
| Setting | Recommended value |
| ------------------- | ------------------------------ |
| Go to Update Screen | Matching Update Form |
| Title | Human-readable identity field |
| Allow Search | On for larger edit lists |
| View Type | List |
| Add New Item | On only if create belongs here |
## Testing checklist
* [ ] Row opens Update Form with the correct record
* [ ] Save on Update Form writes to Notion
* [ ] Search/filters still find the right editable rows
* [ ] Data Restriction / visibility correct per persona
* [ ] Add New Item (if on) opens Create Form
## Troubleshooting
| Symptom | Likely cause | What to check |
| ---------------------- | -------------------------------- | ----------------------------- |
| Row opens wrong screen | Go to Update Screen mis-set | Behaviour |
| Cannot edit fields | Update Form Logic missing inputs | Update Form Content |
| Empty list | Filtering / Data Restriction | Content Filtering + Behaviour |
## Best practices
* Use Update List for operator “find and fix” desks.
* Use View List + Details when users need a read-first experience.
* Keep the Update Form field set small so edit stays fast.
# Form (Update One Item)
The **Form (Update One Item)** screen edits an existing Notion record. It is usually opened from Details (**Allow Editing**) or from **List (Update Items)**.
{% hint style="info" %}
**Who this guide is for**\
Makers configuring edit forms. This guide covers Content/Behaviour options for Update Form, including how it differs from Create Form (no Public access, no section stepper).
{% endhint %}
## What the screen is for
### Use Form (Update One Item) when
* Users change fields on an existing record
* Details should stay read-focused while edit lives on a separate form
* You need after-save Actions or delete from the edit surface
### Do not use it when
* Users only create records: use **Form (Add Item)**
* Users only view: use **Details**
* Guests should submit new intake: use Create Form + Public access (Update Form has no public panel)
## What users see in the live app
* Editable fields for the open record
* Submit button (when editable comps exist) with placement settings
* Optional Delete (non-primary screens)
* Optional after-save Actions
## Add Form (Update One Item) in the builder
1. **Screens → + New Screen** → database → **Form (Update One Item)**.
2. Add editable fields under **Content → Logic**.
3. On Details, enable **Allow Editing → Go to Update Screen** pointing here.
4. Configure Save Button Text, Success Message, and Actions.
5. Publish and test edit→save→Notion sync.
## Complete Builder Options Reference
### Content tab
#### Logic
**Field / component list**
**What it does:**\
Defines which properties users can edit (and read-only comps if included).
**How to use it:**\
Include fields users actually change. Hide system fields. Use visibility logic for role-specific edits.
**Why / recommended default:**\
Keep edit forms tighter than Details. A common mistake is allowing edits to fields that workflows own.
#### Filtering (primary only)
**Filter rows**
**What it does:**\
Scopes records when this Update Form is used as a primary screen.
**How to use it:**\
Usually empty when opened from Details/List with context. Use when Update Form is a primary gated editor.
**Why / recommended default:**\
Empty for secondary edit forms.
### Behaviour tab
#### Save Button Text / positions / Success Message
**What it does:**\
Submit chrome for saving changes. Hidden if the layout has no explicit editable comps.
**How to use it:**\
Label as “Save changes”. Match mobile/desktop placement to Create Form patterns your users already know.
**Why / recommended default:**\
Always provide a clear save label and success message.
#### Actions
**Action Type / + Add Action**
**What it does:**\
After-save Change Data / Go to Screen / Open Link.
**How to use it:**\
Often Go to Screen back to Details or List after save.
**Why / recommended default:**\
Return users to the record they edited.
#### Allow Delete (non-primary)
**What it does:**\
Delete the current record from the edit form (with confirmation options).
**How to use it:**\
Enable only for trusted editors. Prefer confirmation on.
**Why / recommended default:**\
Off unless delete is a real product requirement.
#### Screen Visibility Logic (primary)
**What it does:**\
Who can open the Update Form when it is primary.
**How to use it:**\
Restrict to roles that may edit. Secondary edit forms usually inherit access via Details navigation.
**Why / recommended default:**\
Unrestricted secondary; restrict if primary.
### Appearance tab
Empty — use field inspector + app theme.
### Differences from Create Form
| Option | Create Form | Update Form |
| ------------------------------ | ----------- | -------------------------------------- |
| Public access / Copy form link | Yes | No |
| Use sections as steps | Yes | No |
| Filtering | Never | Primary only |
| Delete | No | Non-primary yes |
| URL default prefills | Common | Less common; still available per field |
### Field inspector highlights
* Is Required, Validate input
* Disable Changes (lock fields)
* Visibility When: current row vs user inputs
* Default Value (use carefully on updates)
## Recommended default setup
| Setting | Recommended value |
| --------------- | --------------------- |
| Opened from | Details Allow Editing |
| Fields | Editable subset only |
| Success Message | “Changes saved” |
| Actions | Return to Details |
| Delete | Off |
## Testing checklist
* [ ] Details Edit opens this form with the same record
* [ ] Save writes to Notion
* [ ] Required/validation rules work
* [ ] Actions return to the expected screen
* [ ] Delete (if on) confirms correctly
* [ ] Role visibility works with `View as user`
## Troubleshooting
| Symptom | Likely cause | What to check |
| -------------------- | ---------------------- | -------------------------------- |
| No submit button | No editable comps | Logic fields |
| Opens blank | Missing record context | Navigation from Details/List |
| Public link expected | Wrong screen type | Use Create Form for guest intake |
## Best practices
* Keep Update Form focused on mutable fields.
* Let workflows own status fields when automation sets them.
* Always provide a return path after save.
# Form (Add Item)
The **Form (Add Item)** screen creates new Notion records. It is the intake surface for requests, applications, feedback, and any “submit something new” flow — including public guest forms in private apps.
{% hint style="info" %}
**Who this guide is for**\
Makers building create/intake forms. This guide explains every Create Form option on **Content** and **Behaviour**, including Public access, submit placement, section steps, and after-save Actions.
{% endhint %}
## What the screen is for
### Use Form (Add Item) when
* Users create new database rows
* Guests should submit without seeing the private app (Public access)
* You need success messaging and follow-up Actions after save
* You want a section stepper for longer intakes
### Do not use it when
* Users only browse existing rows: use **List**
* Users edit an existing row: use **Form (Update One Item)**
* The page is static content: use **Content**
## What users see in the live app
* Input fields in Logic order (and optional section steps)
* Submit button with your Save Button Text and placement settings
* Success message after save
* Optional post-save Actions (change data, go to screen, open link)
* Public forms can open via shareable link without login when Public access is on
## Add Form (Add Item) in the builder
1. **Screens → + New Screen** → database → **Form (Add Item)**.
2. Add inputs under **Content → Logic**.
3. On **Behaviour**, set Save Button Text, placement, Success Message, and Actions.
4. For guest intake on a private app, enable **Public access** and test the copied form link signed out.
5. Optionally enable **Use sections as steps**.
6. Publish and submit a real test record.
## Complete Builder Options Reference
### Content tab
#### Logic
**Field / component list**
**What it does:**\
Defines inputs, sections, and display comps on the form.
**How to use it:**\
Add required intake fields first. Use Section comps to group long forms. Avoid optional noise on the first screen of a stepper.
**Why / recommended default:**\
Short forms convert better. A common mistake is mirroring every Notion property.
Create Form does **not** show screen-level Filtering.
### Behaviour tab
#### Public access (private apps)
**Public access / guest nav / signed-in nav / Copy form link**
**What it does:**\
Lets anyone with the form link submit without signing in. Guest and signed-in navigation toggles control menu visibility. Copy form link builds a shareable URL (needs app domain).
**How to use it:**\
Enable for public intake. Usually keep guest navigation off and link from a public Content page. Copy and test the link in an incognito window. See [Per-Screen Public Access](https://docs.notionapps.com/guides/per-screen-public-access).
**Why / recommended default:**\
Public on only for forms that are safe for unauthenticated submitters. Never expose private data fields.
#### Save Button Text / Mobile position / Desktop position / Desktop alignment
**What it does:**\
Controls submit label and where the button sits on mobile and desktop.
**How to use it:**\
Use action verbs (“Submit request”). Pick Fixed at bottom on mobile for long forms. On desktop, End of form content or Sticky page footer are common.
**Why / recommended default:**\
Clear label + always-reachable button. Floating can help very long forms; test on real devices.
#### Use sections as steps
**Use sections as steps**
**What it does:**\
Turns Section components into a multi-step wizard (Create Form only).
**How to use it:**\
Add Section comps in Logic, then enable this toggle. Keep each step short.
**Why / recommended default:**\
On for long intakes; off for 3–5 field forms.
#### Success Message
**Success Message**
**What it does:**\
Text shown after a successful create.
**How to use it:**\
Confirm what happened and what happens next (“Request submitted — we’ll email you”).
**Why / recommended default:**\
Always set a human success message. Empty success states feel broken.
#### Actions
**Action Type / + Add Action**
**What it does:**\
Runs after save: Change Data, Go to Screen, or Open Link (one navigation-style action max).
**How to use it:**\
Go to Screen for a thank-you Content page or status screen. Change Data for status defaults. Open Link for external confirmation pages.
**Why / recommended default:**\
Prefer an in-app thank-you screen for private apps; Content thank-you for public intake.
#### Screen Visibility Logic (primary)
**Visibility / + Add Logic**
**What it does:**\
Who can open the form when it is a primary screen.
**How to use it:**\
For staff-only create forms, restrict by role. For public forms, Public access is the guest path — still publish and test both guest and signed-in.
**Why / recommended default:**\
Unrestricted for most intake forms unless role-gated.
### Appearance tab
Empty — field styles are in the field inspector; theme is in Settings.
### Field inspector highlights
* **Is Required**
* **Validate input** (Email / Phone)
* **Default Value** (Static or From URL parameter) — see Prefill guide
* **Visibility Logic**
* **Show Scanner** on text inputs
* Section title/description for stepper sections
### Related setup outside the inspector
* List **Add New Item** can open this form
* Content page links often deep-link to this form
* Edit Navigation name/icon and Public badges
## Recommended default setup
| Setting | Recommended value |
| --------------------- | ----------------------------------------- |
| Logic | Only fields required to create the record |
| Public access | On for guest intake; off for staff-only |
| Guest navigation | Off if linked from Content |
| Use sections as steps | On for long forms |
| Success Message | Explicit confirmation |
| Actions | Go to thank-you Content or status screen |
## Testing checklist
* [ ] Required fields block empty submit
* [ ] Record appears in Notion immediately
* [ ] Success message and Actions run
* [ ] Public link works signed out (if public)
* [ ] URL prefills work (if configured)
* [ ] Section steps advance and validate
* [ ] Desktop/mobile submit placement usable
## Troubleshooting
| Symptom | Likely cause | What to check |
| ----------------- | ---------------------------------- | ---------------------------------- |
| Guest sees login | Public access off / not published | Behaviour → Public access; Publish |
| Submit missing | No editable comps | Content → Logic |
| Prefill empty | URL param / Default Value mismatch | Field inspector defaults |
| Stepper confusing | Sections not used or toggle off | Use sections as steps |
## Best practices
* Ask only what you need at create time; edit the rest later on Update Form.
* Pair public forms with a public Content landing page.
* Test signed-out before sharing links.
# Content
Learn how to use Content screens for landing pages, help pages, public entry points, and static app content.
Content screens let you add a freeform page to a NotionApps app without connecting the screen to a Notion database. Use a Content screen when you need a welcome page, instructions page, landing page, help page, policy page, onboarding page, or public introduction page around the data-driven parts of your app.
Unlike List, Details, or Form screens, a Content screen is not for viewing or editing Notion records. It is for the static or semi-static information that helps users understand where they are, what they should do next, and how to move through the app.
## When to use a Content screen
Use a Content screen when the screen is mostly explanatory, branded, instructional, or navigational.
Good examples include:
* A public welcome page before users sign in.
* A landing page that explains what the app does.
* A help page with instructions for using the app.
* A policy, consent, or terms page.
* A dashboard introduction that links users to the right forms or lists.
* A lightweight marketing-style page inside a private or mixed public/private app.
* A launch page with buttons or links to public intake forms.
* A support page with contact details, process notes, or frequently asked questions.
Use a database-backed screen instead when users need to browse records, open one record, create records, update records, filter rows, or see live Notion data.
## Before you start
Before adding a Content screen, decide what job the page should do.
Ask these questions:
* Is this page for guests, signed-in users, or both?
* Should the page appear in navigation, or should users only reach it from a link or button?
* Does the page need to send users to a Form screen, List screen, Details screen, or external website?
* Is the app public, private, or a private app with selected public screens?
* Does the page need simple rich text, or does it need custom HTML and CSS?
This matters because Content screens can be used as public entry points in private apps, but only if you intentionally enable public access for the screen.
## Step 1: Add a Content screen
1. Open the app in the NotionApps builder.
2. Go to the screen list or screen management area.
3. Select **Add Screen**.
4. Choose **Content page** from the available screen types.
5. Give the screen a clear navigation name, such as **Welcome**, **Instructions**, **Help**, **Start Here**, or **About**.
The screen type may appear as **Content page** in the picker and as **Content** in navigation or short labels.
## Step 2: Open the Content page editor
After the screen is created, the builder opens the Content page configuration panel.
This panel is where you edit:
* The page content.
* The optional HTML source.
* The optional CSS source.
* Public access settings, when the app is private.
* Guest and signed-in navigation visibility, when public access is enabled.
* The live preview of the page.
The default content starts with a simple welcome message. Replace it with the copy, links, and layout that fit your app.
## Step 3: Use the visual editor for normal content
For most makers, the visual editor is the easiest place to start.
Use the visual editor to add:
* Headings.
* Paragraphs.
* Bullet lists.
* Numbered lists.
* Bold and italic text.
* Links.
* Images.
The visual editor is best when you want a clean page and do not need advanced layout control. You can write the page almost like a help article or landing-page draft.
Good visual-editor content usually has:
* A clear heading at the top.
* A short explanation of what the user can do.
* One or two obvious next actions.
* Links to the most important forms, lists, or external resources.
* Short sections instead of one long wall of text.
## Step 4: Add links carefully
Content screens are often used to route users to the next part of the app.
You can add links to:
* Another page in the same published app.
* A public Form screen link.
* A help article.
* A website.
* A payment, booking, or support link.
For best results:
* Use full `https://` URLs for external websites.
* Test every link in the published app after publishing.
* If the link should be available to guests, make sure the target screen is also public.
* If the link goes to a Form screen in a private app, make that Form screen public when guests need to submit it without signing in.
Same-app links are handled inside the app shell when possible, so users do not unnecessarily lose the app experience.
## Step 5: Add images
Images can make a Content screen feel more useful and polished.
Use images for:
* A logo or brand header.
* A process diagram.
* A screenshot that shows what users should do.
* A simple hero image.
* A visual explanation of a workflow.
Image URLs should use `https://`. Avoid images that are very large, private, temporary, or hosted somewhere that may block public access. If an image appears in the builder but not in the published app, check whether the image URL is publicly accessible.
Keep the page readable on mobile. Large images should support the content, not push the important action too far down the page.
## Step 6: Use HTML mode only when you need more control
The Content screen also includes an HTML editing mode for makers who need more control over layout.
Use HTML mode when you need:
* A multi-section landing page.
* Custom spacing.
* Button-style links.
* A custom grid or card layout.
* A more branded welcome page.
* More control than the visual editor provides.
HTML mode is powerful, but it is still intentionally limited for safety. Content screens are not a place to run custom JavaScript.
The system removes or blocks unsafe content such as:
* `
