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:viewlets 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:
customersinvisibleAreasshows the Customers tab.
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
customersis invisibleAreas, the role must also havecustomers:viewpermission. The permissions matrix enforces this automatically — enabling an area’s visibility adds the:viewpermission if it is missing. - Data access does not force visibility. Granting
customers:viewdoes not automatically addcustomerstovisibleAreas. The sidebar stays unchanged.
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.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 ahiddenTabs 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.
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 aresource: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.

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.
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:viewbut withoutcustomersin 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_paymentsremoves 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.
Related
Users & Roles
Manage team members, assign roles, and configure permissions.
Sidebar Navigation
How the admin sidebar is organized and what each section contains.