Audit log: finding out who changed what

Audit log, under Settings in the admin nav, is an append-only record of tracked changes in the org. Each row identifies the actor, action and entity; before/after details depend on what that action records. Use it for when a board member asks "who changed the late fee" or "when was this household's role changed." Eligible non-financial changes from the last 30 days can be undone from this page.

Every tracked mutation in the platform. A settings edit, a role grant, an API key created or revoked, portal access provisioned, a ticket or workflow action: writes one row here at the moment it happens. The log is append-only: existing rows are never edited or deleted, so it's a reliable record even if the underlying data later changes again. An undo writes a new row rather than rewriting history.

The audit log is restricted to the treasurer and admin roles. That's narrower than most /admin/* pages, which are open to managers too. The before-and-after detail in this log can span every part of the club, not just front-desk data, so it's held to a tighter tier. A manager who opens /admin/audit is turned away.

The audit log page gives you three filters, usable alone or together:

• Entity type: a dropdown of every entity type that has at least one entry in this org's log (e.g. household, invoice, ticket).

• Action prefix: a text field matching the start of the action name, e.g. ticket. matches ticket.create and ticket.close; settings. matches every settings change.

• Entity id (UUID). The exact id of one record, when you already know it. When the entity type is a household, its id in the results links straight through to that household's record.

Click Filter to apply, or Clear to reset. Results page newest-first; use the pagination control at the bottom to page back through older entries there's no way to jump to a specific date, only to keep paging back. An empty result means no entries match the current filters; change or clear a filter to try again. It does not prove that no changes occurred.

Each row shows the time, the actor (a staff name, or a system/webhook/API key label when the change wasn't made by a person), a plain-language Action (for example "Household updated"), and the entity it touched. The technical action code stays under the label in smaller type for support. Open Show what changed under Detail to expand the recorded before and after values. Not every action has both sides: a creation has no "before," and some actions only record an "after."

Treasurer and admin can Undo a restorable entry. Undo is available when all of these are true:

• The entity type is allowlisted: household members (user), dependents (including allergy and pickup-contact replacements), documents, saved segments, workflows, facility reservations, blackout dates, closures, and waitlist entries.

• The entry is within 30 days.

• Nothing newer has been recorded on the same record (a later edit would be overwritten, so undo is blocked).

• This entry has not already been undone.

Financial rows (invoices, payments, credits, bonds, membership charges, orders, camp registrations) cannot be undone from the audit log, corrections are new rows, never reverse-applied. Tickets, settings, and other non-allowlisted types also have no Undo control; the reason is shown on the row.

Undo also requires the platform to be able to tell what kind of change it's reversing: a change type not yet wired up for agent access can show an Undo button on an otherwise-allowlisted row, but clicking it reports "This change can't be undone from here" instead of completing. This is expected to shrink over time, not grow, as more change types are wired up.

Undoing a saved segment's creation deletes the segment and clears the saved-segment pointer on campaigns that pointed at it (those campaigns keep the frozen audience definition they already stored). That campaign unlink is itself written to the audit log.

Undo this batch (directory)

Bulk tag and opt-in edits on Households share one batch id. After a bulk member update succeeds, the result banner includes Undo this batch, which reverses every still-restorable row from that request and reports how many succeeded if some cannot (for example a member was edited again afterward). The public API's member bulk-update uses the same grouping; undo from the API is not exposed. Use the audit log or the directory banner from an admin session that ran the bulk UI.

Use the audit log to:

• Resolve a "who changed this" dispute: the entry shows the actor, the timestamp, and the exact before/after values.

• Confirm a settings edit or role grant actually landed, and see what the prior value was.

• Spot-check API key creation and revocation history.

• Answer "who closed (or reopened) the books for March?": month-end close and reopen each write an entry (accounting_period.close / accounting_period.reopen) with the actor, the timestamp, and the period. Reopening also requires a reason, entered in the reopen form and captured in the entry's after payload alongside the period. The explanation lives in the log itself, not just wherever the treasurer wrote it down (see Reports and CSV exports).

• Undo a recent allowlisted change, or a regretted bulk member edit, while it is still within 30 days and has not been overwritten.

For anything older than 30 days, or a financial correction, make the correcting change in the relevant admin page; the audit log will record that as its own new entry.