The audit log
/logs. Requires audit.view.
A searchable, clickable record of who did what across the system.
What is recorded
Section titled “What is recorded”Effectively everything that changes state or grants access:
| Area | Examples |
|---|---|
| Authentication | Sign-in, sign-out, failed attempts, MFA changes |
| Submissions | Created, status changed, assigned, closed, outcome recorded |
| Tickets | Created, replied, closed, merged |
| Loans | Issued, returned, registered, bulk actions |
| Devices | MDM commands sent |
| Directory | Licence changes, locks, delegations, password resets |
| Charges | Raised, approved, declined, waived |
| Configuration | Modules, workflow, roles, users, branding, connectors |
| Integrations | API keys issued and revoked, webhooks added |
| Backups | Run, verified, failed |
| Vendor access | Every action a vendor engineer takes on a managed deployment |
Every entry carries who, what, when, and what changed.
Append-only
Section titled “Append-only”Entries cannot be edited or deleted through the application. That is what makes it an audit log rather than a history feature.
What is not recorded
Section titled “What is not recorded”Secret values. Configuring a connector is logged; the token you pasted is not.
Read operations, mostly. Looking at a person’s profile is not logged. Changing it is. A log of every page view would be large and would bury the entries that matter.
Message bodies. That a ticket reply was sent is logged. The text lives on the ticket.
Using it
Section titled “Using it”Search and filter by actor, action, date and target.
Every entry is clickable, so you go from “somebody changed this submission” to the submission.
What to actually use it for
Section titled “What to actually use it for”Accountability, which is the obvious one. Who closed this, who approved that charge, who sent that wipe.
Troubleshooting, which is the underrated one. “It stopped working on Tuesday” plus the log usually equals “somebody changed a connector on Tuesday”. That is faster than any amount of reading code.
Reviewing access. Once a term, look at what a role has actually been used for. It is usually narrower than what people asked for, and that is a chance to tighten permissions with evidence rather than argument.
Answering a question from outside ICT. A parent disputing a charge, a department asking who granted somebody mailbox access. The log is the answer, and having one is the difference between a conversation and a problem.
Retention
Section titled “Retention”Configurable. Longer is better for investigation and worse for disk and for privacy.
The audit log is the largest table on any mature install, so retention is also the main lever on database size. See audit and retention.
Some jurisdictions set a minimum retention for records of access to student data. Check before setting it short.
Vendor access
Section titled “Vendor access”On managed hosting, every action a vendor engineer takes appears here alongside everything else, attributed to them.
If that is not acceptable, vendor access can be disabled outright from Admin, Compliance.
Permissions
Section titled “Permissions”| Permission | Allows |
|---|---|
audit.view | Read the log |
There is no permission to write to it or delete from it. Nobody has that, including administrators, which is the point.