Review Access Audit
Use the audit tab to review recent access-control changes.
The access audit helps owners and admins understand who changed access settings and when.
Use the audit tab after any sensitive access change and whenever a teammate reports that a page appeared, disappeared, or changed behavior unexpectedly.
Open The Audit
- Open Settings.
- Go to Access Control.
- Open the Audit tab.
- Review recent role, permission, and member access changes.
Use the audit after changing sensitive access or when a teammate reports that a page appeared or disappeared unexpectedly.
What To Look For
- Role changes for a member.
- Direct permissions that were granted or revoked.
- New or deleted roles.
- Permission changes on a custom role.
Read the audit around the time the issue started. A permission change that happened days earlier may still be relevant, but the closest role, module, or direct-permission change is usually the best starting point.
When multiple admins changed access, write down the exact member, role, action, and timestamp before making another change. This keeps the investigation traceable and avoids replacing one access problem with another.
How to Investigate an Access Issue
- Ask the teammate which page or action changed.
- Open the audit tab and look for role, permission, or direct-permission changes around the same time.
- Open the Members tab and confirm the teammate’s current role.
- Open the Permissions tab and verify the role includes the needed permission.
- Check direct permissions for temporary grants or exceptions.
- Confirm the related module is enabled and the plan includes the feature.
The audit explains access-control changes. It does not replace module, billing, or integration troubleshooting, so continue those checks when the audit does not show a relevant access change.
If the audit shows no access change, check whether the user is in the wrong workspace, the module was disabled, the record is archived or restricted by ownership, or the feature is no longer included in the plan.
After a Sensitive Change
For billing, domains, API keys, payment gateways, app credentials, and broad permission changes, review the audit immediately after saving. This gives the owner a record of who made the change and makes it easier to reverse mistakes while the context is still fresh.
For temporary access, add a follow-up task to review and revoke it. Direct permissions are useful for exceptions, but long-lived exceptions are harder to reason about than a clear role.
If the change affects integrations or public assets, also check the owner of the connected app, token, domain, mailbox, form, or payment gateway. Access audit shows permission changes, but operational ownership may live on the connected record.
Audit Review Routine
Review access audit after onboarding new admins, changing owner roles, creating custom roles, or responding to an access incident. Capture the member, action, timestamp, and reason in your internal notes when the change affects sensitive modules.
Offboarding Review
During offboarding, use the audit with the member list. Confirm the person no longer has owner/admin access, direct permissions, API key ownership, mailbox ownership, integration ownership, or responsibility for payment and domain settings.
If the person owned records or automations, transfer ownership before removing access so work does not silently stop.
Least-Privilege Review
For quarterly access review, start with admins, owners, custom roles, and direct permissions. Remove old temporary grants first, then simplify roles where the same exception appears across many users.