Loading

Activity Log Overview

The activity log records changes to data: what was changed, from what to what, by whom, and from where.

Where to find it

Architect Panel → Activity:

  • Activity Log — the console — search and filter every change
  • Record Read Log — the separate record of who has read data
  • Audit Chain — the tamper-evidence over these entries

What an entry holds

  • Datastore and record — what was touched.
  • Action — insert, update or delete.
  • Before and after — the row as it was, and as it became.
  • Who — the acting identity.
  • IP address — where the request came from.
  • Timestamp.
  • Chain fields — the hashes that make the entry tamper-evident.

Before and after is the point

Most audit logs record that a record was updated. This one records the row as it was and the row as it became.

The difference matters enormously in practice. "Case 4471 was updated by J. Patel at 14:02" tells you almost nothing; being able to see that the priority went from High to Low and the owner changed is the actual answer. It also means a mistaken change can be reversed from the log rather than reconstructed from memory.

Identity is stored in three parts

Who did something is recorded as a method, a unique ID and a domain rather than as a single user name.

This is what keeps the log unambiguous when people arrive by different routes — an interactive login, an API client, a single sign-on identity, a background task. A bare username cannot distinguish "Jo signed in and changed this" from "an API client acting as Jo changed this", and those are different events with different implications.

It also survives renaming. An identity that is a stable ID plus its domain still resolves after somebody changes their display name or their e-mail address.

Reading is logged separately

Changes are here; reads are in the Record Read Log. They are kept apart because their volume and their purpose differ — a busy system generates far more reads than writes, and the questions asked of each are different.

The log is not the record

Use the log to explain how the current state arose, not as a place to store business information. A note about why something was changed belongs in the record's own timeline, where people will look for it; the audit log is a technical record that most users never see.

Retention

Audit volume grows with use, and it grows fastest on the datastores that matter most. Decide how long you need to keep it — usually driven by your regulatory position rather than by disk — and set retention deliberately rather than discovering the answer when a table becomes unwieldy.

Worked example

A customer disputes a change to their account limit. The log shows the limit changed from £5,000 to £15,000 at 16:41 on 3 March, by an API client acting under an integration identity, from a known address. The before-and-after makes the change unarguable, and the three-part identity makes it clear no member of staff typed it — which redirected the investigation to the integration in minutes rather than days.

Recommendations

  • Reach for before-and-after first in any data dispute.
  • Do not put business context in the audit log — use the record's timeline.
  • Set retention deliberately before volume forces the decision.
  • Note the identity method, not just the name, when investigating.