Permissions control what each user can see and do. They are enforced on the server, used in search and filters, and applied before AI context is assembled.

The aim is for access to feel explicit enough that a small organization can reason about it without permissions getting in the way.

• Primary Owner: the single configured business identity. The Owner has full application access, governs the Administrator roster, protects the canonical Owner account, and can download secret-bearing installation configuration.
• Administrators: trusted managed users who can administer ordinary settings, users, groups, ingress, exports, and content. They cannot change the Owner or another Administrator, govern the Administrator roster, or retrieve installation secrets.
• AI access is separate: promoting a user to Administrator does not enable AI. AI entitlement is assigned independently.
• Groups: users inherit permissions from every group they belong to.
• Most permissive wins: if one group grants view and another grants edit, the user can edit.
• Higher actions include lower actions: edit includes view; delete includes edit and view.
• Pages belong to categories: editing a category lets a user add pages to it. Create permissions are for making new containers such as categories or projects.

1. Global permissions govern broad areas: models/content, forms, and users.
2. Entity permissions grant access to specific categories, projects, pages, or groups.
3. Form restrictions hide pages or tasks that use a restricted form.
4. Page restrictions lock a single page to the owner or selected groups.

The first two layers grant access; the last two only take it away. A form or page restriction can hide something from people outside a chosen group, but it never grants access on its own, so a restriction can only narrow what someone already reaches, never widen it. That makes restrictions safe to add to a working setup.

Forms act like content types, so restricting a form restricts that type of content wherever it appears. In one category, everyone might see ordinary records while only a manager group sees review, compensation, legal, or finance forms.

Because the restriction follows the form rather than the folder, it can carve an exception out of an otherwise shared space. That makes “everything except” access easy to state without touching each record: a group can see every page in a category except the few built on a restricted form, or every task except the ones that use it. The exception travels with the content type wherever it moves.

It is a flexible pattern, and it works best when the form and page restrictions for a given record are set up intentionally rather than as an afterthought.

Restricted content is left out of rendered pages, search results, filter results, and direct route access, not just hidden in the browser. Access is applied as results are gathered, so restricted items are never loaded and then hidden after the fact — there is no partly built page for a restriction to leak out of.

Every page can show who is able to view it. That view is as clear as your group and restriction setup, so a little care with naming groups goes a long way.

• Lean on groups for the heavy lifting and use page-level restrictions for genuine exceptions.
• Keep group names readable; a small naming convention helps when groups start to overlap.
• Remember that global permissions can grant access more broadly than an entity-specific rule.
• Grant category edit when someone should maintain records in an existing category, and reserve model create for people who should create new categories or projects.
• Walk through important flows once from a non-owner account to confirm what other people will actually see.