Access & Permissions

#Overview

This is the one page in this documentation set where Opal's access model is documented in full. Every other page that touches access states briefly what is required and points here.

The model answers a question that comes up constantly as an organization grows: why can this person do that, and why can't I? In Opal, the answer is always some combination of three things, which this page calls the three gates:

1. Plan — the capabilities included in your organization's subscription plan.
2. RBAC — the role permissions granted to you, through a role assigned to you or to a team you belong to.
3. Resource permissions — the permission level you hold on the individual resource you are working with.

An action is available to you only when all three gates allow it. If any one of them does not, the action is unavailable — and knowing which gate is responsible is the difference between a five-minute fix and a support ticket.

Access is scoped to your organization: a single tenant on the Opal platform, and the top-level container that holds its members, teams, roles, resources, and organization-wide settings. Opal treats governance as foundational rather than as something bolted on after deployment — as agents gain access to real information, real systems, and real decisions, oversight and controlled access are what make a digital workforce safe to scale.

#Key Capabilities

• Gate capabilities by plan. Some features are available only on particular subscription plans, so the plan sets the outer boundary of what the whole organization can use.
• Grant organization-wide access with roles. Administrators assign Opal's platform-wide preset roles, or custom roles the organization has defined, to individual members or to entire teams.
• Grant access to an individual resource. A resource can be shared with specific members or with teams, each granted a permission level that determines what they can do with it (Business and Enterprise plans).
• Size involvement to the person. The permission levels available differ by resource type — for a space, for example, they are Manage, Access, and View.
• Apply one consistent model. Opal's governance controls follow a common model across resources, so wherever a control is available it behaves the same way.
• Review how access was granted and changed. Organization and resource activity is recorded in a log that shows what changed and who changed it.

#How it Works

Gate 1 — Plan: what your organization is subscribed to decides which capabilities exist for it at all. The subscription plan is managed in Organization Settings, alongside the billing profile, payment methods, and seats. It is a commercial decision with a direct product consequence: a capability the plan does not include is not available to anyone in the organization, whatever their role. Two plan gates are documented in this set, and they show how this behaves:

• SAML single sign-on is an organization security setting available on the Enterprise plan only.
• Resource sharing and permissions — sharing a resource with members or teams and granting each a permission level — is available on the Business and Enterprise plans.

This is the first gate to check when a setting is missing entirely rather than unavailable to one person. If nobody in the organization can see it, it is usually the plan. See Billing & Subscription.

Gate 2 — RBAC: within what the plan allows, your role decides what you can do across the organization. This is role-based access control: an administrator assigns a role to an individual member or to a whole team, and that assignment sets what the people holding it are able to do. There are two kinds of role — preset roles, the platform-wide roles Opal provides to every organization without configuration, and custom roles, which an organization defines for itself when the preset roles do not match the way it works. Either kind can be assigned to a member or to a team, and because teams can contain nested child teams, a role can be assigned to the specific group it belongs to — a department, or one function inside it — rather than person by person. A role distributes access within the plan's boundary; it cannot grant a capability the plan does not include. How roles are created and assigned is covered by Roles & Permissions (RBAC).

Gate 3 — Resource permissions: within what your role allows, the individual resource decides what you can do with it. A resource — an agent, a skill, a flow, a template, a guardrail, a tool, a widget, a space — can be shared with specific organization members or with teams, and each is granted a permission level that determines what they can do with that one resource. Resource permissions and sharing are available on the Business and Enterprise plans, which is the plan gate and the resource gate interacting directly.

The permission levels available differ by resource type. For a space, there are three:

• Manage — view, edit, and use the space, and manage its settings and sharing.
• Access — view, edit, and use the space.
• View — see the space's details.

Opal's governance controls follow a common model, so where a control is available it works the same way across resources — but not every resource supports every control, and the levels themselves are set by the resource type. See Spaces for how permission levels are granted in practice.

Read the three gates from widest to narrowest. The plan decides what the organization can use; role permissions decide what you can do across the organization; resource permissions decide what you can do with one particular thing. Each is checked in its own right, and the narrowest one wins. Being granted Manage on a space does not give you organization-level administrative access, and holding a broad role does not give you a plan feature the organization has not subscribed to.

Authentication is a separate question. Whether you can sign in at all — enforced multi-factor authentication, SAML single sign-on, and the verified email domains that let people join or request to join — is governed by the organization's security settings, covered by Security. The three gates on this page decide what you can do once you are in.

Access changes are recorded. Actions and updates made to a resource and across the organization are captured in a log showing what changed and who changed it, which is what makes an access review possible after the fact rather than only at the moment of granting. See Audit Log.

An example — a setting nobody can see. A team lead reports that SAML single sign-on cannot be configured. Nothing is broken, and no role will fix it: single sign-on is available on the Enterprise plan only, so this is the plan gate. It becomes a subscription question rather than a support ticket.

An example — one person cannot do what colleagues can. A specialist cannot share a space with a colleague. Three checks, in order: is resource sharing included in the organization's plan, given that it requires Business or Enterprise; does her role permit the action; and does she hold Manage on that space, the level that includes managing its settings and sharing? Because her colleagues can share it and she cannot, the plan gate is clearly open — so the answer lies in her role or her permission level on that space, and the fix is to change one of those deliberately rather than widening everything.

#Additional Notes

• This page explains the model, not the current settings. Which plan your organization is on, which preset and custom roles exist, and who holds which permission level on a given resource are all visible in the product — Organization Settings for plans and roles, the resource itself for its sharing. Those are the accurate sources for what is in place today.
• Plan names appear only where a capability depends on them. Business and Enterprise are named here because specific capabilities depend on them. This is not a complete list of the plans available, and this documentation does not publish prices or tiers.
• Not every resource supports every control. The governance model is consistent across the platform, but the controls a particular resource offers — and the permission levels it defines — depend on the resource type.
• Permissions also decide who can approve a change. Where an organization turns on the optional publishing workflow, a new version of a resource cannot go live until a member with the required permissions reviews and approves it. Access therefore governs not only who can edit, but who can release.
• Grant access to teams where you can. People move between functions constantly. Access attached to a team stays correct when you change who is on the team, instead of needing individual grants revisited one at a time.
• Widen deliberately, not reflexively. When something is unavailable, identify the gate first. Raising a role or opening a resource to solve what turns out to be a plan limitation grants access nobody needed.
• Short definitions of the terms used here are in one place: Glossary.

#Related Features

• Governance — The cluster this page belongs to: organization governance, access, and auditing, and how the access model sits alongside versioning, activity logging, and approvals. Governance
• Roles & Permissions (RBAC) — Gate 2 in depth: preset and custom roles, and how they are assigned to members and teams. Roles & Permissions (RBAC)
• Billing & Subscription — Gate 1 in depth: the subscription plan that determines which capabilities the organization can use. Billing & Subscription
• Spaces — Gate 3 in practice: inviting people into a space at the Manage, Access, or View permission level. Spaces
• Audit Log — The record of organization activity, used to review how access has been granted and changed. Audit Log
• Security — Authentication and admission to the organization: enforced MFA, SAML single sign-on, and verified email domains. Security
• Glossary — Short definitions of the access and permission terms used on this page. Glossary