Governance

#Purpose

Your organization is a single tenant on Opal — the top-level container that represents your company and holds its members, teams, roles, resources, and organization-wide settings. Governance is the part of it that deals with oversight: what people and agents are allowed to do, and what record exists of what they did.

Those are two distinct questions, and this cluster is built around them:

• What is allowed? — the access model that decides whether an action is available to you at all.
• What happened? — the record of activity across the organization, showing what changed and who changed it.

Opal treats governance as a foundational, cross-cutting characteristic of the platform rather than something added after deployment. The reason is practical: as agents gain access to real information, real systems, and real decisions, oversight and accountability are what make a digital workforce safe to scale. Governance is also broader than these two pages — permissions, approvals, versioning, and auditability apply across Opal's resources, and this cluster is where the organization-wide view of them lives.

This page is the map. It introduces the two pages in this cluster, explains how they fit together, and tells you where to start.

#In This Section

• Access & Permissions — The single canonical page for Opal's access model: the three gates of plan, role permissions, and resource permissions, the permission levels a resource can be shared at, and how to work out which gate is behind "why can't I do this?". Access & Permissions
• Audit Log — How to review the record of your organization's activity in Organization Settings: what changed and who changed it, why it is worth reading on a cadence as well as after a surprise, and how it differs from the other records Opal keeps. Audit Log

#Key Concepts

Deciding and recording are two different jobs. Access controls decide what can happen; the audit log establishes what did happen. Neither replaces the other. If the wrong change reached a live resource, the log will tell you who made it — but preventing it is the job of role permissions, resource permissions, and approvals. Read the two pages in this cluster as a pair for that reason.

Access is decided by three gates. Whether an action is available to you depends on your organization's subscription plan, the role permissions granted to you through a role assigned to you or to a team you belong to, and the permission level you hold on the individual resource you are working with. All three have to allow it. Identifying the gate responsible is the difference between a deliberate fix and a widened permission nobody needed — the model is documented in full in Access & Permissions.

Governance controls follow one common model across resources. Wherever a control is available in Opal, it behaves the same way: a resource can be shared with members or teams at a permission level (Business and Enterprise plans); changes are made in a draft and published as a new version, with a version history any earlier version can be restored from as a new draft; linked resources show where something is used before you change it; resource tags classify a growing library; and an optional publishing workflow requires a new version to be reviewed and approved before it goes live. Not every resource supports every control, so check the resource itself for what is available.

One record, two vantage points. Actions and updates made to a resource, and across the organization, are captured with what changed and who made the change. The organization-wide view is the audit log, reviewed in Organization Settings — the central area where an organization's profile and preferences, security, membership, teams and roles, billing, and credits are administered. Governance refers to the same record as the activity log when it is read from a single resource's history. See Audit Log.

Governance applies at two levels, and both matter. Organization-level controls decide who is in and what they can do broadly; resource-level controls decide what happens to one agent, skill, or flow. A compliance lead protecting a customer-facing agent uses both: a role that limits who can administer the organization, sharing that limits who can edit that agent, and the publishing workflow so a new version is approved before customers see it.

Some governance controls are documented elsewhere in this section. Roles and role assignment are covered by Roles & Permissions (RBAC), and organization-wide tags by Resource Tags. This cluster is the access model and the organization's record of activity.

Short definitions of the terms used here are in one place: Glossary.

#Where to Start

Start with Access & Permissions. It is the canonical page for the access model that every other page in this documentation set points to, and understanding the three gates makes the rest of organization administration far quicker to reason about.

Then read the two pages in this order:

1. Access & Permissions — learn the three gates, the permission levels a resource can be shared at, and how to diagnose an action that is unavailable. Access & Permissions
2. Audit Log — learn how to review what changed across the organization and who changed it, so an access review or an investigation starts from facts. Audit Log

If you are here for one thing — working out why a colleague cannot do something, or checking who changed a setting — go straight to the page that covers it.

For the rest of organization-level administration — the organization's profile and preferences, members and access, billing and credits, and platform configuration — start from Organization.