Governance and audit log

The Governance screen answers the two questions a security review always asks: who did what, and who may do what. It holds the organisation's audit log — a tamper-evident record of every change — and the roles, including custom roles that limit a person to certain areas of the product. You need it for security questionnaires, internal audits, or simply to find out who changed a setting.

#Where to find it

Press ⌘K (Ctrl+K on Windows) and search for Governance, or go to https://app.rixe.ai/governance. The People tab of Settings also points here: members and invites are managed in settings, roles and the audit log live on this screen.

The audit log is visible to owners and admins.

#The audit log

Every request that changes something in your organisation is recorded: creating, editing and deleting, from the panel or from the API. Requests that were refused or failed are recorded too — a denied attempt is often the interesting part. Reading data is not logged, so the record stays focused on changes.

The Audit logs table has five columns:

#Filtering and exporting

1. Use the pills at the top of the table — All, Succeeded, Denied, Failed — to filter by result.
2. The screen shows the last 30 days by default. Add ?days=90 (up to 365) to the address to look further back. At most the 1,000 most recent events in the period are shown.
3. Click Download CSV to export the same events with date, user, action, result and IP.

#Chain validation

Each audit record carries a hash of its own contents and of the record before it, so the records form a chain. The banner at the top of the screen re-checks that chain every time you open it:

• Chain validation: intact — for example "120 records checked, the chain is intact."
• Chain validation: broken — "The chain breaks at record …: a row before it may have been deleted or altered."

A broken chain means the record was changed outside the product. The log is append-only: nobody, including the owner, can edit or delete entries from the panel or the API.

Audit records are kept for seven years. When an organisation is deleted, the events remain but the personal fields (who, IP address, browser) are emptied — see Data and security.

#Custom roles

The built-in roles — Owner, Admin, Member and Viewer — are described in Team and roles. A custom role narrows one of them to a list of areas. It can only take permissions away: a custom role never grants more than the built-in role it is based on.

A custom role has:

• a name,
• a base role: Admin, Member or Viewer,
• the areas it may use.

The areas are:

A request into an area the role does not include is refused with "Your custom role does not include the … area." Screens that belong to none of these areas are not narrowed by a custom role; the base role still applies to them.

#Ready templates

The Roles card lists four ready templates, so the common cases need no planning:

#Creating and assigning a custom role

Custom roles are created and assigned by the owner. The Roles card shows the organisation's custom roles with their base role and areas, or "No custom role defined yet." There is no role editor in the panel yet; contact us to create one or to assign it to a member.

• A newly assigned custom role takes effect at the person's next sign-in.
• Deleting a custom role does not lock anyone out: members who had it fall back to their built-in role.

#Common questions

Why doesn't the audit log show who opened a report? Only changes are logged. Reading data does not create a record.

Can I delete an entry that was logged by mistake? No. The log is append-only, and removing a row would break the chain.

A member can't open the Governance screen. The audit log is limited to owners and admins.

#Related pages

• Team and roles
• Single sign-on
• Data and security