Reading the audit log

The audit log records what people did in your account: sign-ins, permission changes, exports, legal holds, View as sessions and changes to records. It is the screen to reach for when the question is “who changed this, and when”. Each action is one row, however many records it touched.

Where to find the audit log

Choose Admin, then Developer in the left-hand menu and Audit logs.

What each row of the audit log shows

Column	What it tells you
When	The date and time of the action, in UTC
Who	The person who did it, with their work ID, or the system for scheduled and automatic work
Record type	The kind of thing it happened to: a person, a course, a learning record, a department
Action	What happened, in one word. Red means something was removed (Deleted, Revoked), green that something was added or achieved (Created, Completed), amber that something changed (Updated)
Did what	The action as a sentence, naming the record it happened to. A long sentence is cut short: point at it to read it all, or open the entry

A change to your organisation’s settings names the area rather than a record, for example Updated account settings or Updated AI settings. Switching positions on or off reads as exactly that: Switched positions on. Each choice made while setting positions up is its own entry too, naming the positions involved.

When an action was about one record inside another, such as a learning record deleted on a person, Did what ends with that record’s status and date. Ten deletions on one course then read as ten different records rather than ten identical lines.

The times are UTC, not your local time. The column is headed When and does not say so, which makes it the thing to check before concluding that two events happened in the wrong order or that somebody was working at an implausible hour. The date itself follows the date format you use in Learnient.

Seeing the full detail of an audit log entry

Choose View details on a row. The panel has four parts:

• Overview — the sentence, when it happened, the action, who did it and whether that was a person, an integration or the system, the channel it came through (web, mobile app, API) and the area of the product
• Record — the record the action was about, any related record, the Records affected with each one’s status and date at the time, and anything the action recorded about itself, such as the reason given for a View as session
• Changes — each field that changed, read as previous → current. A deletion shows only what the record held, and a creation only what it was created with
• Context — the event ID, the request ID, the IP address and the device

Records affected lists each record once, one per line. It leaves out the bookkeeping Learnient does behind a change, such as the history kept when a manager changes, so moving someone’s manager lists the people it moved rather than every row it wrote.

Copy event details puts everything in the panel on your clipboard as plain text. It is the quickest way to hand a single entry to someone else.

Finding out who deleted a particular record

A deleted record keeps its values in the audit log after the record itself is gone. Open the deletion and Changes shows what it held, such as its status, score and dates, while Records affected names it with its ID, status and date.

That is what answers “who deleted the passed attempt, not the failed one”. Filter to the Record type and to the Action Deleted, then compare the status and date on each row.

Filtering, searching and exporting the audit log

Filters narrow the list by Date range, Record types, Actions, Who, Areas and Channels. The search box looks through the names and labels on each entry, and the list sorts by When, newest or oldest first.

Export downloads what you are looking at as a CSV file, up to 50,000 rows, and the export is itself recorded in the log. Filter before exporting rather than after: an unfiltered export of a mature account is not something anybody reads.

How long the audit log keeps entries

Entries are not kept for ever. Three retention periods apply, by what kind of event it is:

What it records	Kept for
Security events — sign-ins, password and token events, permission changes, View as sessions, legal holds, exports and deleted learning records	730 days
Changes to records and learning activity	180 days
Sign-in attempts against an address that is not a user	90 days

Pruning runs on a schedule rather than at the moment a row expires, so an entry a day or two past its period may still be there.

Two years is the window for security questions. An investigation into who had access when, or who exported what, has a two-year memory. For ordinary record changes you have six months.

Keeping audit log entries for longer than their retention period

There is no setting to extend retention, and nothing warns you as an entry approaches its date. If you need a record to outlive it, export it.

A legal hold on a person or on your whole organisation pauses pruning of the entries it covers for as long as it is in place. It does not extend the retention period: once the hold is released, the next prune removes anything already past its date. See How purging and legal holds work.

View as and support sessions in the audit log

Every View as and support session is written into this log as it starts, stops, is revoked or expires. That is deliberate, and it is the only place those sessions are shown — see How View as sessions are restricted and recorded.