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.
• Provider access is separate: promoting a user to Administrator does not enable Lagniappe-funded model calls. That entitlement is assigned independently; provider-free external-agent plans still follow normal permissions.
• Groups: users inherit permissions from every group they belong to.
• Most permissive wins: group and individual grants combine. If one group grants view and another grants edit, the user can edit, subject to applicable restrictions.
• 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 limit a single page to Administrators 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.

Ordinary users must satisfy every applicable restriction: if both a page and its form name groups, they need membership in at least one group from each list. Tasks and files can inherit those restrictions. Application Administrators, including the Owner, bypass content restrictions.

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.

For a user without access, restricted content is left out of rendered pages, search results, and filter results. Direct links enforce the same permissions on the server; hiding a control in the browser is not the access boundary.

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.

Signed-in public accounts use a separate, limited public-permissions policy. They are different from anonymous visitors reading a published page document. Publishing a document shares that document, without publishing the page’s private form answers, tasks, notes, or uploads.

• 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.