Audit Log

Every organization accumulates changes that nobody remembers making. A pass appears on a member’s account, a price is different from what you agreed, a session that was on the timetable last week is gone. The audit log answers those questions directly: who changed what, and when.

Where to find it

The log lives in the app sidebar under ADMINISTRATION, at Audit log.

Who can see it

The audit log is gated on its own permission, “View Audit Log” – described in the permissions list as “View the organization audit log”, in the Audit Log category. By default only owners hold it.

That permission is separate from everything else, which means you can open the log up without opening anything else up. You have two ways to do it:

• Give it to a role. Grant View Audit Log to the Admin, Trainer or Member role in role configuration, and everyone with that role can read the log.
• Give it to one person. Add a permission override on a single member, and only that person gets it.

Either way, nothing else about that role or that person changes. See Role Management for how role configuration and per-member overrides work.

What the log records

The audit log records staff actions – things people with access do to your organization and to other people in it. Entries fall into five groups, and those same five groups are what you filter by:

• Passes & money – passes granted and deleted, a pass’s price or validity changed, pass requests approved or rejected.
• Access & permissions – roles changed, members removed, guests created, claim and setup links issued, booking blocks cleared, invitations created, bulk-created and deleted, permission overrides added and removed, and role configuration changed.
• Scheduling – timetables deleted and cancelled, sessions cancelled, uncancelled and overridden, share links generated and revoked.
• Bookings & attendance – bookings made or cancelled by staff on someone else’s behalf, and attendance marked, both one member at a time and in bulk.
• Settings – organization settings and locales changed.

What the log does not record

A member booking their own session, or cancelling their own booking, is not written to the audit log. That is deliberate. Ordinary self-service traffic is the highest-volume thing that happens in a studio, and if it were in here it would bury the handful of entries you actually came looking for. The log is about staff acting on other people, not about members using the app normally.

If you want to see a member’s own booking activity, look at that member’s profile and booking history instead.

Filtering

Three filters narrow the feed:

• Action – pick one of the five groups above. With nothing selected it reads Any action.
• Who acted – pick the person whose actions you want to see. With nothing selected it reads Anyone.
• Date range – a From and a To date.

Changing any filter takes you back to page one, so you are never looking at page four of a result set you just replaced. A single control clears all of the filters at once.

The feed shows 25 entries per page, newest first.

Reading an entry

Each row has five columns: When, Who, What, Target and Details. Who is the person who acted, Target is the person or object they acted on, and Details carries whatever is specific to that action – the amount on a pass, the reason on a cancellation, and so on.

Times are on the studio’s clock

Both the From / To filters and every timestamp in the feed are read in your organization’s timezone. “Today” means the studio’s civil day. An owner checking the log from another country sees the same day boundaries and the same times as an admin standing in the studio – the device’s clock is never used. See Timezone for the setting itself.

Entries outlive the people in them

Names in the log are snapshots, captured at the moment the action happened. That is what makes old entries still readable: if a member is deleted, or a pass template is renamed, or a timetable is removed entirely, the entry that mentions them still says what it said the day it was written, rather than turning into a blank or a broken reference.

When someone is deleted

Deleting a person does not erase their trail – it pseudonymizes it. Their name and email are replaced with a short, opaque reference along the lines of “Staff member #a91f”, while the action, the target and the timestamp stay exactly as they were. Because that reference is derived from the account itself, it is always the same one: all of that person’s entries still match each other, so you can still see that a single individual did all of those things, even though you can no longer see who it was.

Deleted account in the Who column is a different thing – it is what the feed falls back to for an entry that never captured a name, rather than the marker for someone who was deleted.

The reason is simple: if deletion wiped the entries instead, deleting an account would erase precisely the history the audit log exists to hold.

Why entries can be trusted

An entry is written in the same database transaction as the change it describes. The practical consequences are worth stating plainly:

• An action that failed and rolled back leaves nothing in the log.
• An entry never describes a change that did not actually happen.

There is no separate “log it afterwards” step that could quietly fail on its own.

How long entries are kept

Entries are kept for about 24 months and pruned nightly.

Platform operator activity

Trainery staff can act on your organization through support access. That activity is recorded, but it is kept in a separate platform-level log rather than in your feed, and it is never attributed to your owner account. So an entry in your audit log always reflects someone from your own organization, and support work never shows up as though you did it yourself.

Two things this version does not have yet: there are no per-object History tabs, so you read the log as one feed rather than from inside a pass or a session, and there is no member-facing view – members still see only their own pass history.