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 controls whether the page appears in the sidebar and search and whether the route lets you in. On the Finance pages it is also a database rule that stops a member or viewer reading the records: Estimates, Expense claims, Assets and Liabilities by their own box, and Invoices, Bills, Credit notes, Payment receipts, Bank accounts, Suppliers, Repeating money and the books once every page that shows the same records is off. Owners and admins are never limited by View. On every other page it is not a database rule yet.
• View-only is enforced by the system on these pages tooWhen a page is set to view-only for someone (View ticked, Create/Edit/Delete off), the database itself refuses their changes, not just the hidden buttons. This covers Products (including stock adjustments), Liabilities, Expense claims, Meetings, Invoicing (creating an invoice from a deal), Payroll (preparing a run), Bank accounts (connecting or editing an account), Keys (creating an AI-assistant key), Users (deleting a role template) and Signing (sending a request). The primary owner is never restricted. On every one of these pages, a save that is refused because your own page permission is off names the page and the action: “You can view Products but not create it. Ask an owner or admin for access.” That includes creating an AI-assistant key, sending a signature request, deleting a built-in role template, preparing a payroll run and ending a meeting.
• 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.