Change log

The change log answers one question: what changed in the system, by whom, and when. It is a table rather than a set of panels, because that question is open-ended, asked across thousands of rows, and usually answered with a file.

The other question — "how did this record end up like this?" — is asked while looking at the value you doubt, so it is answered by the timeline on the record itself, not here.

The columns

Column	What it holds
When	Date and time
Who	The actor, under the display name they had at that moment
Actor type	A person, a token, a scheduled process, a board capture, or the system itself
Entity type	Event, role, token, server record…
On what	The specific record, linked to its screen
Action	Create, edit, delete, cancel…
What changed	The fields that changed, from value to value

Clicking a row opens all of its changes, together with the reason the actor stated, the actor's id, and — on a token's row — the token's owner.

Five actor types

Type	Who it is
User	A person who signed in
Token	An access token, with its public id — so a change made by a since-revoked token stays attributable
Process	A sync or scheduler running with no human in the loop
Board capture	The narrow credential that photographs a dashboard for a scheduled report
System	The application itself: install, upgrade, startup

Filtering: the query versus the result

The top bar — from date, to date, entity type, actor — narrows the query, because the log is too large to load whole. The default is the last thirty days. The column filters and chips below narrow the result that is already loaded.

The two are shown separately and labeled differently precisely so an empty table is not read as an empty log. When the first batch does not cover everything in the range, the screen says how many of how many loaded and offers to narrow.

The log inherits the product's whole table machinery: sorting, column filters, saved views, and export to CSV and Excel. What an auditor actually asks for — "every change to this system between these two dates, as a spreadsheet" — is exactly those.

What you see and what is omitted

The audit permission opens the screen. It does not widen what you may read: a row usually carries the very value the record's own permission exists to withhold, so entity types you may not read are omitted from the result.

They are omitted rather than refused with an error, because the existence of a record is itself information. The screen states how many types were omitted — a list that quietly got shorter is indistinguishable from a fault.

The trail of a single record needs only that entity's own view permission, so a register's custodian sees their register's history without a global audit right.

Older entries with no "before"

Some older entries were written before the log kept the previous value, and hold only what was recorded after the change. They are shown as that — as the values recorded, not as a move from one value to another. Inventing a previous value nobody captured is exactly the failure an audit trail exists to prevent, and it would be invisible.

Retention

The default is to keep forever. An audit log that prunes itself is a compliance defect wearing a housekeeping costume, and evidence of a change is asked for years afterwards.

Anyone who does want pruning sets a number of days in the system settings. Three rules bound it:

• Pruning is not automatic. It runs from a scheduled task or from the button on the screen.
• A dry run comes first. It reports how many rows would be deleted and up to which date, deleting nothing.
• Nothing below thirty days is ever deleted, whatever is typed in the box. A typo in that number cannot erase this month.

The prune itself is recorded in the log. A deletion inside an audit log is an audited action in its own right.

The volume panel at the foot of the screen shows how many entries there are, the oldest one, how many arrived in the last thirty days and what that means per year — with the policy currently in force beside them.