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

You have more than one screen.
You know the primary role’s “home” screen.
You have decided public vs private. Public apps still have nav; they just have no login chrome.

Build it

Open Edit Navigation (builder, Screens rail or the nav editor).
Choose the mobile pattern: bottom tabs or drawer.
Choose the desktop pattern: TOP_TABS or DRAWER (DesktopNavigationType).
Drag screens into the order users should see. First item is what most users treat as home unless you set a Profile landing screen.
Optionally create navigation groups (section labels in the drawer).
For each role that needs a different menu, configure that role’s visible screens. See Roles and navigation.
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.
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.
Reuse screen	Title-bar action	Second nav entry for the same screen.
Detach	Title-bar action	Turns one reused tab into its own cloned screen.
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.

Reuse, Duplicate, and Detach

Use these when the same screen should appear more than once in the tab bar or drawer.

Action	What it does
Reuse screen	Adds another nav entry that still points at the same screen. Edits stay in sync.
Detach	Shown when a screen is in navigation more than once. Clones this tab so you can edit that copy only.
Duplicate Screen	Makes a full independent copy immediately (including secondary Details / forms).

A reused screen shows Also in navigation as the other tab names, plus Detach to edit this copy only.

Maker walkthrough: Reuse a Screen in 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. Reuse vs Detach: Reuse a Screen in Navigation.