Skip to main content
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:
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.
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.
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?”

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.
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.