For the complete documentation index, see llms.txt. This page is also available as Markdown.

🏎️App Navigation

One page for how users move through the app: mobile bottom tabs vs drawer, desktop top tabs vs drawer, role-specific nav, and screens hidden from navigation (deep links only).

Navigation Groups and Screen Navigation Visibility stay as short pointers to this page. Those pages link here for the full navigation guide.

What this is / when to use it

Navigation is the chrome around your screens: the tab bar, the drawer, and the desktop top tabs. It is not the same as screen visibility (who may open a screen) or data restriction (which rows they see).

Use this page when you are deciding:

  • Tabs vs a drawer on phones

  • Top tabs vs a drawer on desktop

  • Different menus per role

  • A screen that should exist but not appear in the menu (Select Items, a success content page, a deep-linked form)

When not to use navigation as a security control: hiding a screen from the menu does not hide it from a crafted URL if the user is allowed to open it. Use screen visibility and private apps for access.

Before you start

  1. You have more than one screen.

  2. You know the primary role’s “home” screen.

  3. You have decided public vs private. Public apps still have nav; they just have no login chrome.

Build it

  1. Open Edit Navigation (builder, Screens rail or the nav editor).

  2. Choose the mobile pattern: bottom tabs or drawer.

  3. Choose the desktop pattern: TOP_TABS or DRAWER (DesktopNavigationType).

  4. Drag screens into the order users should see. First item is what most users treat as home unless you set a Profile landing screen.

  5. Optionally create navigation groups (section labels in the drawer).

  6. For each role that needs a different menu, configure that role’s visible screens. See Roles and navigation.

  7. For picker / success / wizard screens, turn Hide from navigation on. Give them an opener (button, form redirect, relation). See the how-to Open Screens That Are Hidden From Navigation.

  8. Preview phone and desktop. Publish.

Every control

Control
Options
What it does

Mobile nav

Bottom tabs / drawer

Phones and the “show mobile view on desktop” preview.

Desktop nav

TOP_TABS / DRAWER

Large-device chrome.

Large device view

DESKTOP / MOBILE

Force the mobile layout on desktop. See Desktop view.

Screen order

Drag list

Tab / drawer order.

Navigation group

Label + member screens

Drawer section headings.

Hide from navigation

On / off

Screen stays in the app, omitted from chrome.

Role menu

Per-role screen set

Different tabs for Client vs Staff.

Profile landing

Everyday chrome Profile

User-chosen default screen. See Profile.

App icon / colour / URL

Brand

Not nav structure. See App Icon, Colour, URL.

Bottom tabs work with a small set of top-level screens (about 3–5). More than that belongs in a drawer, or in tabs plus hidden deep links.

Hide from navigation

Turn Hide from navigation on for picker, success, and wizard screens. The screen stays in the app and is omitted from the tab bar and drawer. Users reach it from a button, a form redirect, a relation picker, or a published URL. Hiding a screen is not access control — use screen visibility and private apps for that.

What users see

Mobile bottom tabs. A bar at the bottom. Extra screens go into an overflow if you add too many — prefer fewer tabs.

Mobile drawer. A menu icon. Groups appear as headings.

Desktop top tabs. A horizontal bar. Long lists wrap or overflow; prefer a drawer when you have many roles and many screens.

Desktop drawer. Persistent or hamburger, matching the mobile mental model.

Hidden screens. No tab. Users reach them from a button (go_to_screen), a form submit redirect, a relation picker, or a published URL that includes the screen slug.

Limits and plans

  • Hide-from-nav is not access control.

  • Role menus still require the user to be in that role in the Users database.

  • Custom domain and slug changes do not reset nav, but they do change deep-link URLs. See Publish & share.

  • Everyday chrome screens (Home, Search, My Queue, Activity, Profile) are normal nav citizens. Put Home first and Profile last unless you have a reason not to.

Example

A mixed portal:

Screen
Nav
Who

Home

First tab

All signed-in roles

My requests

Tab

Client

Work queue

Tab

Staff

Add request

Hidden

Opened from Home primary CTA

Choose scopes (Select Items)

Hidden

Opened from the form relation

Legal (Content)

Drawer group “Account”

All, also marked public

Staff and Client do not share the same tab set.

Fix problems

Symptom
Likely cause
What to do

Screen missing from tabs

Hidden, or role menu excludes it

Check hide-from-nav and role config.

Users open a hidden screen from a stale link

Visibility still allows them

Tighten screen visibility if that is wrong.

Desktop looks like a phone

Large device view is MOBILE

Set DESKTOP.

Two nav docs disagree

Groups / visibility pages are stubs

This page is canonical.

Next: Add New Screen or Types of Screens. Screen who-can-open rules: Screen Visibility.

Last updated