The Audit Log and Approvals

Two features answer "who did that?", from opposite ends. One is after the fact; the other is before it.

Audit Logs — after the fact

Audit Logs in the left navigation. An append-only record of what changed, who changed it, and when.

Use it when:

• A price is not what it was.
• A permission has drifted.
• A payment was edited or deleted.
• A setting changed and nobody remembers doing it.

The log is read server-side with filters, sorting and paging, because it grows without limit. Filter to the day and the area first rather than scrolling.

Audit log notifications in Communications can push a message when something notable happens, so you find out at the time rather than during an investigation.

Requests — before the fact

Requests in the left navigation. Instead of catching a change afterwards, route it through approval.

Depending on your configuration, these can become requests:

• A member changing their own schedule. They are told explicitly that it is a request, because their calendar has not actually moved.
• A member changing other preferences about themselves.
• A payment being updated or deleted.
• A client rescheduling, with Require Approval for Client Appointment Update.
• A client cancelling, with Require Approval for Client Appointment Cancellation.
• Being added as a collaborator, with Approval required for collaboration.

Approvals are visible on the web and in the app, and request notifications in Communications tell approvers there is something waiting.

Which to use where

Approvals for the small number of things that are expensive to undo: payments, schedules, anything touching money.

The audit log for everything else. Requiring approval for everything means approvals stop being read, which is worse than not having them.

Monitoring

Monitoring is the live view: what is happening in the business right now, across devices and staff. The audit log is history; monitoring is the present.