Shared permissions and entitlements

Overview

In Ottili ONE, permissions and entitlements are not confined to a single product. They are shared across the company* and apply consistently across every active module*. Two layers work together:

• Roles* decide who in the company can see and do what.
• Entitlements* (capability grants) decide which features are available to the company at all.

Both layers are always evaluated in the company context (company_id). There is no global, cross-company access and no implicit inference of a company context.

Roles as the shared foundation

Ottili ONE uses five roles: Owner*, Admin*, Manager*, Employee* and Viewer*. These roles are company-wide — they apply across the whole platform, not just within one module.

A role determines, for example, whether a user can activate modules, change settings, edit records, or only read. The exact split of rights per role is described in [Roles and permissions](/docs/roles-and-permissions).

Entitlements: a shared, tenant-scoped model

The entitlement engine* is the single, company-scoped decision authority for capability grants. For exactly one explicit company context it combines every dimension into a deny-by-default* verdict:

• the company's plan (plan)
• purchased add-ons (purchases)
• approved trials (trials)
• Free-Forever inclusion
• administrative grants (grants)
• region
• product status (product status)
• company suspension (suspension)

Every decision is an explicit grant with state, source and classification:

Hard gates:* when a company is suspended, everything is denied. When a region is not allowed or a product is blocked, the capability is denied by default. The company context is never inferred from a first membership or a global default — the evaluation requires the context explicitly.

Module activation and default permissions

When a module is activated for a company, the platform automatically grants its default permissions* to the company's standard roles — Owner*, Admin* and Manager*, plus any role that already holds a permission for that module. This makes a module usable immediately, without a manual grant round-trip.

On deactivation or removal, those default permissions are revoked again. Every grant is:

• explicitly tenant-scoped* — every record carries company_id;
• idempotent* — reactivating does not create a duplicate grant;
• reconcilable* — revocation on deactivation is recorded, not silently overwritten.

Shared effect across modules

A user with a given role and a company with given entitlements experience the same permission foundation in every active module*. Modules share the company context; permissions are not reinvented per module. This means: someone allowed to edit data in Business Hub does so under the same role as everywhere else.

Approvals for sensitive actions

Some actions require human sign-off before they run. They land in the approval queue*, where an authorized person countersigns. This applies to both human users and automated flows. See [The approval queue](/docs/approval-queue) for details.

Support AI within the permission framework

Ottili AI operates strictly within the permissions it is granted. It can only read the data, tools and modules it is connected to, and it can never take an approval-required action without a human countersigning. The permission framework therefore applies to the AI as well.

Distinguishing status clearly

Features and products move through clear status stages. The entitlement engine reflects product status: a blocked product is denied by default.

Related articles

• [Roles and permissions](/docs/roles-and-permissions)
• [The approval queue](/docs/approval-queue)
• [Company and team](/docs/company-and-team)
• [Workspace and modules](/docs/workspace-and-modules)