Audit Log

#Overview

The audit log is the record of your organization's activity: what changed, and who changed it. Administrators review it in Organization Settings, the central area where an organization's profile and preferences, security, membership, teams and roles, billing, and credits are managed.

Its value is simple and it shows up at exactly two moments. When something behaves unexpectedly, the audit log tells you what actually happened instead of what people remember happening. And when nothing is wrong at all, it lets you confirm that the organization is being administered as expected — a periodic review rather than an emergency one.

The same record is named in two places in Opal, and it is worth knowing both names: the audit log of organization activity in Organization Settings is referred to as the activity log in Governance, where actions and updates made to a resource, and across the organization, are captured with what changed and who made the change.

This matters more as a digital workforce grows. Opal treats governance as foundational rather than as something added after deployment: as agents and people gain access to real information, real systems, and real decisions, a traceable record of what changed and who changed it is part of what makes that safe to scale.

#Key Capabilities

• Review organization activity in one place. View an audit log of organization activity from Organization Settings, alongside the settings the entries relate to.
• See what changed and who changed it. Every entry carries both halves of the question: the action or update, and the person behind it.
• Cover resources as well as the organization. The same log model captures actions and updates made to a resource and across the organization.
• Support audits and troubleshooting. The record is traceable after the fact, which is what makes an audit or an investigation possible rather than speculative.
• Confirm the organization is being run as intended. Periodic review is a governance practice in its own right, not only a response to a problem.

#How it Works

The audit log records organization activity. Actions and updates made across the organization — and to the resources within it — are captured in the log as they happen, each entry showing what changed and who made the change.

You review it in Organization Settings. An organization's settings are managed from one central area, and the audit log sits there with the profile and preferences, security, membership, teams and roles, billing, and credits it reflects. That placement is deliberate: the record of a change lives next to the setting that was changed.

One record, two names. In Organization Settings it is the audit log of organization activity; in Governance it is called the activity log. It is the same record, described from two vantage points — the organization-wide view, and the view of a single resource's history.

Reading the log is an administrative capability. Who can open it is decided by role permissions, in the same way as the rest of organization administration. This is worth checking before an audit rather than during one: if a compliance or security colleague needs to review activity, they need a role that permits it. See Access & Permissions.

Use it to answer "what changed, and who changed it?" That is the question the log is built to answer, and it is the question worth bringing to it. Start from the change you can observe — an access outcome that surprised someone, a setting that is no longer what you expected — and use the log to establish the action behind it and the person who took it. Because entries name both, the outcome is a fact rather than an inference, and the follow-up conversation is a specific one.

An example — a periodic review. An IT administrator who has rolled Opal out across her company reviews the audit log on a regular cadence, confirming that membership, security, and access are being administered as expected. Most reviews find nothing, which is the point: she is verifying, not investigating, and the record makes that a short task rather than a project.

An example — after an unexpected change. A compliance lead notices that a customer-facing agent is behaving differently from last week. She reviews the log to see exactly what changed and who changed it. From there she can look at the resource's own governance controls — its version history, and the linked resources that show where it is used — and decide what to do next. The log establishes the facts; the resource's controls provide the remedy.

An example — reviewing how access was granted. A member turns out to have access a colleague did not expect. Rather than reasoning backwards from the current state, the administrator uses the log to find the change that granted it and the person who made it, then adjusts the role, team membership, or resource permission deliberately. See Governance for how the log fits alongside Opal's other governance controls.

#Additional Notes

• This page explains what the audit log is for and how to review it, not what every entry contains. The log in Organization Settings is the accurate source for the activity recorded in your organization today, including what is available to you when you open it.
• The audit log is not the only record Opal keeps. Each resource has a version history of its published versions, a webhook keeps its own request log of the requests it has sent, and a task or flow records each execution in its Run Log. The audit log answers what changed across the organization; those records answer what a particular resource, integration, or run did. See Webhooks.
• A record of a change is not a substitute for controlling it. The log tells you what happened after the fact. Preventing the wrong change is the job of role permissions, resource permissions, and the optional publishing workflow that requires a new version to be reviewed and approved before it goes live.
• Review on a cadence, not only on incident. A regular pass over the log is a governance practice; treating it purely as an incident tool means the first time anyone reads it is under pressure.
• Changes to who is in the organization and how they sign in are recorded too. Membership changes and security settings both leave a trace here — see Members and Security.
• 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 activity log sits alongside versioning, permissions, and approvals. Governance
• Access & Permissions — The access model that decides who can review the audit log, and whose grants the log records. Access & Permissions
• Members — Invitations, join requests, and membership changes — organization activity that the log records. Members
• Security — Enforced MFA, SAML single sign-on, and verified email domains; changes to these settings are reviewable in the log. Security
• Webhooks — Outgoing webhooks subscribe to platform events and keep their own request log, separate from the organization's audit log. Webhooks