Access & permissions: how the layers work

What someone can see and do is decided by a small stack of layers, checked in order. Knowing the order is the fastest way to answer “why can/can’t this person do X?” Or just ask Chief the same question and it walks the layers for you.

• 1. Org access levelOwner, Admin, Member, Viewer or Guest (Users ▸ a person ▸ Access & roles ▸ Access level). Owner/Admin manage the workspace; Member works in it; Viewer reads all of it and changes none of it; Guest is limited to the projects they are added to, at one of a few guest levels (Viewer / Collaborator / Contributor).
• 2. Role templateA bundle of module access and per-page Create/View/Edit/Delete you assign to many people at once. It decides which PAGES somebody sees; what they may change is layer 1 above, their access level. The two are separate settings and a role can never widen an access level. If no template is assigned, that person’s own permission toggles and page settings are what apply.
• 3. Per-user overridesA person’s own Page access tree always wins over their role template for the pages it touches. It is a per-page override, not a replacement of the whole template. Untouched pages keep inheriting the role.
• 4. Page CRUD enforcementOn the pages that carry a server rule, Create / Edit / Delete are enforced by the database itself, not just hidden in the UI, so a blocked action fails safely even if someone tries it directly. Coverage is not yet every page: where a rule does not exist the tick hides the button without refusing the write, and the roles editor marks it so you can see which is which. View works differently everywhere: it controls whether the page appears in the sidebar and search and whether the route lets you in, and it is not a database rule on any page.
• 5. Page visibility (the eye toggle)Settings ▸ Modules can hide a page from the sidebar for everyone on a plan/role. This is a cosmetic declutter switch, not a security control. Real protection comes from the database, never from a page being hidden: tenant isolation on every table always, and the per-page write rules on the pages that carry them.
• 6. Plan / module gatingA module can be off for your whole plan (Billing ▸ compare plans) or self-disabled per workspace (Settings ▸ Modules). Either way the module and its data stay invisible until it is turned on.
• 7. Primary-owner exemptionEvery workspace has exactly one PRIMARY owner (the person who created it, or a platform owner) who cannot be restricted by page CRUD or role changes, by design, so the workspace can never be locked out of its own data. If you are testing what a restriction actually does, test with a non-primary account.