How Access Works
YND OS decides what you can see and do based on roles. This page explains the moving parts in plain English so you know why you can (or can't) see a page, and where to send someone who's stuck.
The three layers
- Roles — a small set of job-function labels assigned to your account (for example
csrorproject_manager). - The page registry — a master list, maintained by engineering, that says which roles are allowed to see each item in the sidebar.
- Permission sets — an admin tool for granting extra, one-off page access to a specific person without changing their role.
If any of these three say "yes," you see the page. If none of them say "yes," you land on /access-denied.
The 10 roles
| Role key | Label | Typical person |
|---|---|---|
door_expert | Door Expert | Field sales rep (e.g., Phil) running consultations and proposals |
csr | CSR | Customer Service Rep taking calls, booking appointments (e.g., Danielle) |
project_manager | Project Manager | Runs field capture, scope validation, releases jobs (e.g., Sergio) |
dispatcher | Dispatcher | Schedules and routes appointments |
design_concierge | Design Concierge | Helps customers pick products/finishes |
reconciler | Reconciler | Validates scope against what was sold |
manager | Manager | Oversees a team; broad visibility |
executive | Executive | Company leadership; sees everything |
installer | Installer (read-only) | Field installer; view-only access to Projects |
admin | Admin | Runs the app: users, permission sets, integrations |
Note: One person can have more than one role. Roles are additive — having any one of the allowed roles for a page is enough to see it.
The page registry
The sidebar (and top nav) is generated from a single list in the app's code called the page registry. Each entry has:
- A label (what you see in the sidebar, e.g. "Payments")
- A path (the URL, e.g.
/payments) - An optional list of roles allowed to see it
If a page has no roles listed, it is visible to every signed-in user, regardless of role. Right now that applies to Mission Control (/), Communications (/communications), and Training (/training).
Tip: See /help/permissions/page-access-matrix for the full table of every nav item and every role.
The registry only controls what shows up in the sidebar and produces the checklist admins see on /admin/permission-sets. It does not, by itself, stop someone from typing a URL directly into the browser — see /help/permissions/known-gaps for which routes are and aren't protected that way.
Admin and Executive bypass everything
admin and executive roles automatically see every page in the sidebar, no matter what roles are listed for that page. This is a deliberate shortcut: it means admins and execs never get stuck waiting on a permission-set update to check something.
This also means the sidebar looks identical for Admin and Executive users. The real difference between them is server-side: only Admin can actually invite new users or edit permission sets on /admin/users and /admin/permission-sets — an Executive who tries will be blocked by the server even though the buttons appear.
Permission sets: granting extra access
Sometimes someone needs access to one extra page that isn't part of their normal role — for example, a CSR who occasionally needs to see the Price Book. Rather than changing their role (which would open up everything tied to that role), an admin can grant a permission set.
Permission sets are managed on /admin/permission-sets (admin only) and work as a checklist of page keys per user. A user's final access is: role-based pages + any pages granted via permission set.
Warning: Permission sets are currently underused across the team — most people only have the default access from their role. See /help/rollout/open-decisions for the recommendation to standardize one permission set per role instead of ad hoc grants.
What happens when you're denied
If you try to open a page your role and permission sets don't allow, you're redirected to /access-denied. This is a plain "you don't have access to this page" screen — it does not tell you which role would grant access, so if you hit it unexpectedly, ask your manager or an admin rather than guessing at what changed.
See /help/troubleshooting/access-denied for the full troubleshooting steps.
Worked example
Jane is a CSR. She signs in and sees: Mission Control, Dispatch, Routing, Customers, Opportunities, Communications, Payments, Appointments, Call Recordings, Schedule, My Schedule, Gallery, and Training — because her csr role is listed on each of those pages (or the page has no role restriction at all).
She does not see Field Portal, Proposals, Price Book, Catalog, Configurator, Imagine, Inspirations, or any Admin pages, because csr isn't on those lists and she has no permission set granting them.
If Jane types /pricebook into the address bar, she'll be denied. But if she types /estimate or /bookings/new, she'll get in — those routes aren't gated at all yet. See /help/permissions/known-gaps for the full list.
Where to go next
/help/permissions/page-access-matrix— the full role × page table/help/permissions/known-gaps— routes that aren't gated, and open questions/help/troubleshooting/access-denied— what to do when you hit the wall