AUDIT TRAIL
Every action leaves a trace.
Who did what, when, on which field, and on whose behalf.
Three names on every entry
The direct author, whoever triggered it, and the human at the top of the chain. When an agent edits a record, the trace does not say “system”: it says which agent, launched by whom, on whose behalf.
The author's address is copied into the entry at write time, so someone leaving the company does not erase the history.
The detail, field by field
An update records the old and the new value of every field it touched. For a relation field, the label of the target record is frozen at write time: renaming a client tomorrow does not rewrite what was read yesterday.
In the interface, every field carries its own history, right next to it. You do not open a separate log to find out where an amount came from.
What must not be written is not written
Passwords, tokens, secrets, API keys, card numbers: those values are redacted before the entry is written, not at display time.
The distinction matters. Redacting on display leaves the value in the database, where it eventually resurfaces in an export. The log does not become the new place where what you protected elsewhere leaks.
The log obeys the same permissions
Reading a record's history requires the right to read the object it belongs to. The audit trail does not open a back door onto what you are not allowed to see.
More than twenty-five actions are covered: records, schema objects and fields, people, roles, settings, files.
How it works
“That amount was 12,000 last week.” Someone has to know who changed it, and on what basis.
An action goes through: a record created, a field edited, a role assigned, a file uploaded.
The service composes the entry, redacts sensitive fields and freezes relation labels.
The entry is written with its author, its delegation chain and its timestamp.
You read it back from the record, from the field, or by filtering the log.