Known Access Gaps
This page exists so nobody is surprised. YND OS's page registry controls the sidebar, but a handful of real pages can still be reached by typing a URL directly, regardless of role. This is a known, tracked limitation — not a secret. If you're a manager or admin reviewing security/rollout readiness, this is the page to check.
Warning: "Ungated" means any signed-in user — regardless of role — can open the page by typing its URL, even if it never appears in their sidebar.
Ungated routes (any signed-in user can URL-hop)
| Route | What it is | Risk |
|---|---|---|
/bookings/new | CSR 4-box booking intake (Align, Diagnose, Design, Decide) | A non-CSR could create bookings/start recordings |
/estimate | Estimate builder | A non-sales role could build/see pricing |
/workbench/:proposalId | Proposal Workbench (assign items, warranties, send) | A non-sales role could edit/send proposals |
Most /admin/* pages | Includes several internal tools beyond the ones listed in the page registry (e.g. /admin/servicetitan-mapping, /admin/integrations/framer, /admin/data-management, /admin/pricing-*, /admin/products*) | Anyone signed in could view or change integration/pricing configuration |
/csr-intake | Legacy CSR intake page, superseded by /bookings/new | Confusing duplicate flow, also ungated |
The page registry only lists roles for pages that appear in the sidebar. Some /admin/* pages are gated (Users, Permission Sets, Tags, Warranty Content, ServiceTitan Integration, Internal Notes Guidelines, Sales Coaching, Feedback) because they're in the registry — the risk above is specifically the other admin tools that exist in the codebase but were never added to the registry.
Note: This is tracked as a checklist item in /help/rollout/pre-launch-checklist — closing this gap means adding these routes to the page registry with sensible role lists before wider rollout.
Ambiguous or intentional-looking gaps
These aren't necessarily bugs — they may be intentional — but they haven't been explicitly confirmed, so we're documenting them as open questions.
1. Communications and Training visible to everyone
Both /communications and /training have no role restriction — every signed-in user sees them. This might be intentional (company-wide comms and training should be broadly visible), but it's worth explicitly confirming rather than assuming.
2. Executive and Admin have an identical sidebar
Both roles bypass all page gates, so their UI looks the same. The real distinction is enforced server-side: only Admin can invite users or edit permission sets on /admin/users and /admin/permission-sets. An Executive will see those pages and their buttons but will be blocked by the server when trying to actually invite someone or change a permission set. This can be confusing without a heads-up.
3. /approvals (manager approvals queue) is not in the sidebar
The page exists and works, but there's no link to it anywhere in the nav. Managers who need it must be told the direct URL. This should either be added to the sidebar for manager/executive, or intentionally kept as a direct-link-only page — but right now it's just missing.
4. Legacy /csr-intake page
This predates /bookings/new and appears to be a leftover. It's ungated (see above) and not linked from the sidebar, but it still works, which means old bookmarks or muscle memory could route CSRs through the outdated flow.
Structural/process gaps (not page-gating, but related)
- Permission sets are underused. Most users only have their role's default access; almost nobody has been granted a permission set yet, even though the tool exists on
/admin/permission-sets. - Demo data flag. The app has a demo-data mode; it must be verified off for production users before go-live.
- No staging environment. There's currently no separate staging deployment — all testing happens against the same environment used in the field.
See /help/rollout/pre-launch-checklist and /help/rollout/open-decisions for how these are being tracked toward launch.
What to do if you find another gap
Tell your manager or an admin, and add it to the pre-launch checklist rather than assuming someone else has already caught it.