Skip to main content
Visible areas determine which top-level sections appear in the admin sidebar for a given role. Hidden tabs extend this to individual in-page tabs — a role can hide specific tabs within a section without removing the section itself. Both are independent from data access permissions.

How it works

Every role — system or custom — carries two separate fields:
  • Permissions — server-enforced data access. Controls what the API returns for a user. Example: customers:view lets the user read customer data.
  • Visible areas — client-side UI presence. Controls which sections appear in the admin sidebar and are reachable by URL. Example: customers in visibleAreas shows the Customers tab.
These two axes are independent. A user can have customers:view permission (to support cross-resource workflows like an order’s customer picker) without the Customers section appearing in the sidebar.

The asymmetric rule

Visible areas follow one directional constraint:
  • Showing an area forces data access. If customers is in visibleAreas, the role must also have customers:view permission. The permissions matrix enforces this automatically — enabling an area’s visibility adds the :view permission if it is missing.
  • Data access does not force visibility. Granting customers:view does not automatically add customers to visibleAreas. The sidebar stays unchanged.
This means you can build roles like “Order Manager with customer data access but no Customers tab” — the user can pick customers from within the order flow without seeing a dedicated Customers section in the sidebar.

Resolution across roles

A user’s effective visible areas are the union of all assigned roles — the system role plus any custom roles. If any role includes an area, that area appears in the sidebar.
The Member system role does not include finance by default, but the “Finance Viewer” custom role adds it. The user sees all seven sections.

Available areas

Visible areas map one-to-one with the top-level admin resources:

Per-tab visibility

In addition to hiding entire sidebar sections, roles can hide individual tabs within a section. Each role carries a hiddenTabs list — an array of resource:subResource keys that identifies which tabs to suppress. Tabs follow intersection (AND) semantics, the inverse of visible areas:
  • Visible areas use union — any role showing an area wins.
  • Hidden tabs use intersection — a tab is hidden only if every role assigned to the user hides it. If any role leaves the tab visible, it appears.
This means a more-permissive role always wins: adding a role never hides a tab that another role shows.
Both roles hide orders:order_payments, so it stays hidden. Only one role hides orders:order_documents, so the Documents tab appears.

Hideable tabs

Every tab in the admin is identified by a resource:subResource key. The full set spans all major areas: Each key is prefixed with its resource in the API (e.g., orders:order_payments). The permissions matrix in the admin displays them grouped by resource with their readable names.
Permissions matrix with per-tab Show in UI checkboxes

System role defaults

Each system role comes with a predefined set of visible areas: Custom roles can extend these defaults by adding areas the system role does not include. System roles do not hide any tabs by default — all tabs are visible. Per-tab hiding is configured only through custom roles.

Usage

Configuring visibility in the permissions matrix

When you create or edit a custom role, the permissions matrix shows a Show in UI column alongside the data access columns (View, Create, Manage, Delete). The column has two levels of checkboxes:
  • Top-level row — controls the sidebar section (visible area). Toggling it on or off shows or hides the entire section.
  • Sub-resource rows — controls individual tabs within that section. Expand a top-level row to see per-tab checkboxes.
The matrix enforces the asymmetric rule at both levels: turning on Show in UI automatically enables View data for that resource or tab. Turning off View data automatically disables Show in UI.

When visibility is hidden but data access remains

A hidden area or tab does not block cross-resource workflows. Common scenarios:
  • Customer picker in orders — a role with customers:view but without customers in visible areas can still search and select customers when creating an order. The Customers section is hidden, but the picker works.
  • Hidden tab, visible data — hiding orders:order_payments removes the Payments tab from the order detail page, but payment data still flows through other views (e.g., order summary totals, reports).
  • Deep links — linking directly to a URL within a hidden area shows an access-restricted page. The data permission still applies server-side, but the admin does not render the page.
Visible areas and hidden tabs are a UI convenience, not a security boundary. They control what appears in the sidebar and on detail pages. They do not restrict API access — data access is governed entirely by permissions.

Users & Roles

Manage team members, assign roles, and configure permissions.

Sidebar Navigation

How the admin sidebar is organized and what each section contains.