> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orriven.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit log

> Every change made in the console, recorded automatically — who did what, to which object, and when.

Orriven keeps a complete audit trail. **Every successful change made through the console is
recorded automatically** — creating an event, publishing a ticket type, changing a member's role,
disabling a redemption code. There is nothing to switch on and no way for a change to slip past
it: recording happens by construction, so a feature shipped yesterday is audited today.

Each entry records:

* **Time** — when it happened.
* **Actor** — the signed-in member who did it.
* **Action** — what kind of change (create, update, and so on).
* **Scope** — where it applies: the organization, one business unit, or one event.
* **Subject** — the object that was changed, with a **Details** view of the recorded entry.

Reading the log requires no extra setup; writing to it is not something you do — the platform
does it for you.

## Three views of one trail

The same trail is readable at three levels, so you look where the question lives:

<AccordionGroup>
  <Accordion title="Organization-wide">
    **Audit log** in the organization section shows every console operation across the whole
    organization — actor, action, scope and time. This is the governance view, available to
    organization owners and admins: use it for "what changed last week, anywhere?" and for
    compliance review.
  </Accordion>

  <Accordion title="Per business unit">
    Each business unit has its own **Audit log** page showing only that unit's slice of the
    trail. A unit's admins see their own team's history without wading through — or being shown —
    the rest of the organization.
  </Accordion>

  <Accordion title="Per event">
    Each event has an **Audit log** page in its navigation: operations on that event — ticket
    types, codes, perks, forms and registrations. This is usually the fastest answer to "who
    changed this ticket type's capacity?"
  </Accordion>
</AccordionGroup>

## Filtering

Large organizations generate a lot of entries. The **Filter** bar above the log accepts simple
conditions joined with `AND` — the hint under the field lists the exact syntax. You can narrow by
the kind of object, the action, the actor, the business unit or event, and a date range, then
choose **Apply**.

Typical questions the filter answers:

* Everything one person did in the last month.
* All changes to redemption codes across an event.
* Every role change in a business unit since a given date.

## Rules to know

* **The log is append-only.** Entries cannot be edited or deleted, by anyone — that is what makes
  it an audit trail rather than a notes field.
* **Only successful changes are recorded.** A rejected or failed attempt did not change anything,
  so it does not appear.
* **Reads are not logged.** The trail records changes, not who looked at what.
* **The organization-wide view is for owners and admins.** Members see the slices their business
  unit roles give them access to.
* **Some pages carry a richer history of their own.** An attendee's detail page, for example,
  shows a registration activity timeline written for reading — approvals, status changes — while
  the audit log stays the formal ledger. When you need the story, look at the page; when you need
  the record, look at the log.

<Tip>
  When something looks wrong — a ticket type off sale, a code disabled — check the event's audit
  log first. "Who, what, when" is usually the whole answer.
</Tip>