Per-Screen Public Access

Learn how to expose selected screens in a private app while keeping the rest of the app behind login.

Per-Screen Public Access lets you make selected screens in a private NotionApps app available to guests without opening the entire app. It is designed for apps that need a public entry point, such as a welcome page, request form, intake form, application form, event signup page, or help page, while keeping dashboards, staff views, customer-only pages, and private records behind login.

With this feature, a maker can choose exactly which screens are public. Guests can open only those public screens. Signed-in users continue to use the private app normally.

Annotated builder screenshot: Per-screen public access overview

What this feature is for

Use Per-Screen Public Access when the app itself should stay private, but one or more screens should be available without login.

Common use cases include:

• A public landing page that explains the app.

• A public intake form that creates a Notion record.

• A public request form for customers, vendors, or applicants.

• A public event registration form.

• A public help or instruction page.

• A private portal where guests first submit information, then staff manage the work privately.

• A mixed experience where guests can start a process, but only approved users can see the rest of the app.

This feature is not the same as making the whole app public. The app can remain private while specific screens become guest-accessible.

Annotated builder screenshot: Public entry with private operations

What this feature is not for

Do not use Per-Screen Public Access to expose screens that show sensitive private records.

Be careful with:

• Customer lists.

• Internal dashboards.

• Staff queues.

• Financial records.

• Private documents.

• User profile screens.

• Screens that depend on the logged-in user.

• Screens with filters that assume a signed-in user exists.

Guests are not signed in, so user-specific restrictions that depend on a logged-in user may not behave the same way as they do for authenticated users. If a screen contains private data, keep it private.

Annotated builder screenshot: Keep sensitive screens private

How guest access works

When an app is private, a user normally has to sign in before they can open the app.

When at least one screen is marked public:

• Guests can open public screens without signing in.

• Guests cannot open private screens.

• Guests cannot use private screen URLs to bypass login.

• Guests only receive data needed for public screens.

• Signed-in users keep the normal private app experience.

The public/private boundary is enforced by the backend. The setting is not just a visual toggle in the builder.

Annotated builder screenshot: Guest access boundary

Step 1: Start with a private app

Per-Screen Public Access is most useful when your app is private.

Before configuring public screens:

1. Open the app in the NotionApps builder.

2. Confirm the app is configured as a private app.

3. Confirm the private screens still require login.

4. Decide which screen or screens should be visible to guests.

If the whole app is already public, users can already open the app without signing in. In that case, Per-Screen Public Access is usually not the setting you need.

Annotated builder screenshot: Start with a private app

Step 2: Choose the right public screens

Choose screens that make sense for unauthenticated visitors.

Good public screen candidates:

• Content screens.

• Add Item / Create Form screens.

• Simple public instruction screens.

• Public request or application forms.

• Public landing pages that link to a form.

Poor public screen candidates:

• Internal list screens.

• Staff work queues.

• Private details screens.

• User profile screens.

• Screens meant only for logged-in users.

• Screens that show records belonging to many customers.

If you are unsure, start with only a Content screen and one Create Form screen. Publish, test, and then add more public screens only if the guest flow truly needs them.

Annotated builder screenshot: Choose safe public screens

Step 3: Turn on Public access for a screen

There are two common places where makers will see the Public access setting.

For many screens:

1. Open the screen list or screen settings area.

2. Expand the screen.

3. Find Public access.

4. Turn it on.

For Content screens and Create Form screens, the public access setting may also appear directly inside that screen's configuration panel.

When Public access is on, anyone with the app link can open that screen without signing in. Other screens remain private unless you mark them public too.

Annotated builder screenshot: Turn on Public access

Annotated builder screenshot: Content page public access

Annotated builder screenshot: Create Form public access

Step 4: Decide if guests should see the screen in navigation

After a screen is public, you can decide whether guests should see it in the app navigation.

Turn on Show in navigation for guests when:

• The screen should be easy for guests to find.

• The screen is the public home or welcome page.

• Guests may need to return to the screen later.

• The public flow includes more than one public screen.

Turn it off when:

• The screen should only be opened from a direct link.

• The screen is a one-time form.

• The screen is only reached from a button on another public page.

• You want guest navigation to stay simple.

A public screen can still be opened by link even if it is hidden from guest navigation.

Annotated builder screenshot: Show in navigation for guests

Step 5: Decide if signed-in users should see the public screen

Public screens can also have separate navigation behavior for signed-in users.

Use Show in navigation when signed in when:

• The page remains useful after login.

• It is a help page, instructions page, or reference page.

• Staff or customers should return to it from the app menu.

Turn it off when:

• The page is only for guests.

• It is only a public landing page.

• Signed-in users should land on a dashboard, list, queue, or private workspace screen instead.

• The screen would clutter the signed-in navigation.

This lets you keep the guest experience simple without polluting the logged-in app experience.

Annotated builder screenshot: Show in navigation when signed in

Step 6: Link public screens together intentionally

Public screens often work best as a small path.

Example path:

1. Guest opens a public Content screen named Welcome.

2. The Welcome page explains the process.

3. The page links to a public Create Form screen named Submit Request.

4. The guest submits the form.

5. Staff handle the new record from private screens after signing in.

When building this path, every screen that guests need to open must be public. If a public Content screen links to a private Form screen, guests will be asked to sign in or may not be able to complete the flow.

Annotated builder screenshot: Public Content + form path

Step 7: Be careful with Details and Update screens

Some screens open other screens as part of the normal app experience.

For example:

• A List screen may open a Details screen.

• A List screen may open an Update Form screen.

• A button may send users to another screen.

• A form action may redirect users after submit.

If a guest needs to open the destination screen, that destination screen should also be public. If the destination is private, the guest should not be able to open it without signing in.

This is especially important for list-to-details flows. A public List screen that leads to a private Details screen will create a confusing guest experience unless the maker intentionally wants the details view to require login.

Annotated builder screenshot: Linked destinations must match guest flow

Step 8: Test while signed out

Testing while signed out is the most important step.

Open a private or incognito browser window and test as a guest:

1. Open the published app link.

2. Confirm the public screen opens without login.

3. Confirm guest navigation only shows the screens guests should see.

4. Click every link and button on the public screen.

5. Submit any public form.

6. Confirm the private screens still require login.

7. Confirm the guest cannot reach private dashboards, lists, or staff screens.

Do not rely only on the builder preview. Always test the published app while signed out.

Annotated builder screenshot: Test while signed out

Step 9: Test while signed in

After testing as a guest, sign in as a normal app user.

Check:

• The signed-in user lands on the correct screen.

• Guest-only public screens are hidden from signed-in navigation if you turned that setting off.

• Useful public pages remain visible if you intentionally kept them in signed-in navigation.

• Private screens still work normally.

• Data restriction and user-specific views still behave correctly for logged-in users.

This confirms the public guest path did not make the private app harder to use.

Annotated builder screenshot: Test while signed in

Recommended patterns

Public landing page plus public form

Best for intake, applications, requests, and lead capture.

Recommended setup:

• Content screen: Public access on.

• Content screen: Show in navigation for guests on.

• Content screen: Show in navigation when signed in off, unless it is also useful after login.

• Create Form screen: Public access on.

• Create Form screen: Show in navigation for guests off if users reach it from the landing page.

• Staff list/details screens: Public access off.

Public help page inside a private app

Best for instructions that both guests and signed-in users may need.

Recommended setup:

• Content screen: Public access on.

• Show in navigation for guests on.

• Show in navigation when signed in on.

• Keep links to private screens clearly labeled for signed-in users.

Direct-link public form

Best when you want to send someone straight to a form from an email, website, QR code, or external page.

Recommended setup:

• Create Form screen: Public access on.

• Show in navigation for guests off.

• Copy and share the form link.

• Test the link in a signed-out browser.

Private portal with no public navigation

Best when the public screen should be hidden but reachable from a controlled link.

Recommended setup:

• Public access on for the target screen.

• Show in navigation for guests off.

• Share only the direct link.

• Keep all other private screens behind login.

Security checklist

Before publishing, ask:

• Does this screen expose any private customer, staff, vendor, financial, or internal data?

• Does the screen depend on a logged-in user's identity?

• Does the screen link to another screen that also needs to be public?

• Does the screen's navigation behavior make sense for guests?

• Does the screen's navigation behavior make sense after login?

• Have I tested the app while signed out?

• Have I tested the app while signed in?

• Can a guest reach only the screens I intended?

If the answer is uncertain, keep the screen private until you can test the flow safely.

Troubleshooting

Guests still see the login screen

Check that:

• The app has been published after changing the screen setting.

• The screen itself has Public access turned on.

• You are opening the correct published app URL.

• You are testing in a signed-out or incognito browser.

Guests can open the landing page but not the form

The form screen also needs Public access turned on. A public Content screen does not automatically make linked Form screens public.

Guests cannot find the screen in the menu

Turn on Show in navigation for guests. If this setting is off, the screen may still be accessible by direct link, but it will not appear in guest navigation.

Signed-in users still see the guest landing page

Turn off Show in navigation when signed in for the public screen. Signed-in users will then use the normal private app navigation instead.

A public List screen opens a login screen when a record is selected

The Details or Update screen behind that list is probably private. If guests should open it, mark the destination screen public too. If guests should not open record details, keep the destination private and consider changing the guest-facing flow.

A public screen is showing more records than expected

Review the screen design carefully. Public screens should only show information you are comfortable exposing to anyone with the app link. If the screen depends on user-specific filters, it may not be a good public screen.

Best practices

• Start with the smallest possible public surface.

• Prefer Content screens and Create Form screens for guest flows.

• Keep private data on private screens.

• Treat public List screens with extra caution.

• Hide one-time public forms from guest navigation when users reach them from a landing page.

• Hide guest-only pages from signed-in navigation when they are no longer useful after login.

• Test every public link while signed out.

• Test the normal app experience while signed in.

• Publish after every access-setting change.

Quick setup checklist

Use this checklist when creating a guest-accessible flow:

• The app is private.

• The guest entry screen is chosen.

• Public access is on for the guest entry screen.

• Guest navigation is configured intentionally.

• Signed-in navigation is configured intentionally.

• Every guest destination screen is also public.

• Private dashboards, staff screens, and sensitive records remain private.

• The app is published.

• The guest flow is tested in an incognito browser.

• The signed-in flow is tested with a real app user.

Builder options at a glance

This guide teaches a focused maker workflow. For the full screen option inventory (What it does / How to use / Why) and annotated builder screenshots, use the matching Types of Screens guide:

• Data screens: List (View Items), Details, Form (Add Item), Form (Update One Item), List (Update Items), Content

• Everyday chrome / Queue & activity: see the Types of Screens index

• Automation native screens: Native Automation Screens

Recommended defaults

• Change one option family at a time, then publish and test on phone and desktop.

• Prefer screen-level settings in Content / Behaviour / Appearance before custom CSS/JS.

• Keep public access and navigation visibility intentional on every screen you link from this guide.