The audit trail, in the staff console

What this screen is for

It answers two questions that nothing else can. Who has looked at this customer's data? and what was this value before somebody changed it?

Both are recorded whether or not anyone ever asks. A trail that only records changes answers the second question and leaves the first with no answer at all, which is why opening an account is written down here exactly like changing one.

What each column means

When

In your own time zone. The row is stored in UTC.

Actor

The person who did it. Every row on this console has one - there are no headless administrative actions.

Event

What happened, as a stable code such as admin.organization.suspended. Codes are what to filter on; the wording beside them may be reworded.

Target

What it happened to, and its identifier.

Before / after

The value that changed, and only that value - not the whole record. Empty on a read, which has no before.

Reference

The correlation id. The same id is on every log line for the request that produced the row, so one value traces an action end to end.

What each control does

Event type

Matches from the START of the code, so admin.organization finds every organisation event and admin.organization.suspended finds only suspensions.

Organisation id

Narrows to one organisation. Take the identifier from its own screen.

Newest first, always, and paginated. The sort is the timestamp with the row's own identifier as a tie-break, because this table takes bursts of writes inside the same millisecond and a sort with ties makes paging skip and repeat rows.

What this screen does not do

Rows cannot be edited or deleted from anywhere in the product. A trail that can be tidied is not a trail.

It holds no request body, no response body, no password material and no token. What is recorded is the value of the thing that changed and a one-line reason - never the record itself, because an audit table that stores whole records is a second copy of the database with none of its constraints.

Reading this screen is deliberately NOT written back into the trail. It would be self-referential noise: each page you opened would push the rows you were looking for onto the next page. The request logs record it, under the same reference.