The audit trail
What is recorded, how to search it, what can be switched off — and the two areas that cannot.
Every action is recorded. The trail lives under Platform → Audit rather than as a short feed on the dashboard, because a trail worth keeping is one you can search.
The record answers for itself
Every record in the platform now carries four columns of its own: who made it, when, who touched it last, and when. They are on the record page under the record id, and they are in the Columns menu of every list — off until you turn them on, and remembered by a saved view once you do.
This is separate from the trail below, and deliberately so. The trail is a searchable history that a retention policy will eventually trim; the four columns are part of the record and stay with it for as long as the record does. "Who changed this credit limit" used to be answerable only by searching a second table, and only until that table had been trimmed.
- They are filled however the record was written — by a form, by an import, by Ask, by the published API or by a routine that never mentions them.
- They cannot be rewritten. The two "created" columns are fixed at the moment of writing and the platform refuses an attempt to set them, whatever the request says.
- "Last modified" moves on every change, and nobody gets an opinion about when a change happened.
- A person who has since been deleted leaves their id; the audit trail can still name them.
- A record written with nobody behind it — a data load, a migration script — says Created by System / data load.
Searching it
The audit log is searched by date and time first, then narrowed by area, action, user, or free text across the recorded detail — including record identifiers and the JSON detail of each change. Results are newest first and paged.
Each row names the record by its number or code (LDR-301, not an internal id), the area in words as the menu names it (HRMS · Training Courses) and the person by name, with their email when you hover. The User filter lists people by name.
Settings
Audit Policy lists every auditable area as a toggle, grouped into Security, Master data, Transaction data and Configuration, with select-all and clear-all and per-group switches. It opens on a tile per group saying how many of its areas are recorded ("N of M recorded"); press one to see its toggles, or Everything to see them all. Everything is on by default; switch areas off to narrow the trail to what you care about.
Two areas are locked on and cannot be switched off: sign-in and sign-out, and role creation and changes. Clear all deliberately skips them, and the API refuses an attempt to disable them individually.
The catalogue is self-extending. If the platform audits an area not yet listed, it is registered automatically — enabled — the first time it occurs, so the settings screen can never be missing an action.