Activity Log

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.

Filtering and Searching Activity

The log's value is entirely in being able to find the entry you want. On a working system that means filtering, not scrolling.

Where to find it

Architect Panel → Activity:

• Activity Log — the console, with its filters
• Record Read Log — the same approach applied to reads

What you can narrow by

• Person or identity — everything one actor did.
• Datastore — everything that happened to one kind of record.
• Record — the full history of one thing.
• Action — inserts, updates or deletes.
• Time range.
• IP address — everything from one origin.

Start with time, then narrow

Almost every investigation begins with a rough idea of when. Bounding the time range first cuts the volume by orders of magnitude and makes every subsequent filter fast.

Starting with a person instead is the common mistake: you get their entire history and then have to find the day in it.

Two directions of enquiry

Investigations run one of two ways, and knowing which you are doing keeps you efficient:

• From the record — "what happened to this?" Filter by record and read the sequence.
• From the actor — "what did this account do?" Filter by identity over a time range.

The second is the security question. A compromised or misused account is investigated by looking at everything it touched in a window, and that is exactly what an identity-plus-time filter produces.

Filter by action for deletions

"What was deleted last month" is a question the action filter answers directly, and it is worth asking periodically even when nothing is wrong. Deletions are the changes people notice last and mind most.

IP address is underused

Filtering by origin address answers questions no other filter can: whether a change came from the office, from a home connection, or from an integration's known address. It is the fastest way to distinguish "somebody used this account" from "something used this account".

Confirm the absence too

When investigating, it is as valuable to establish that an account did nothing in a window as to find what it did. An empty result over a bounded range is evidence; scrolling and not noticing anything is not.

Export what you rely on

If a log extract supports a decision — a disciplinary matter, a regulatory response, a dispute — export it at the time. Retention will eventually remove the entries, and the moment you need them again is exactly when they will have aged out.

Worked example

After a leaver's account is found to have been active for two days after their last day, the log is filtered to that identity over that window. It returns eleven entries, all reads from a single unfamiliar address and no changes. The extract is exported before anything else happens, and the investigation proceeds knowing precisely what was and was not touched.

Recommendations

• Bound the time range first, every time.
• Know which direction you are investigating — record or actor.
• Review deletions periodically, not only after an incident.
• Export anything you will rely on at the moment you find it.

The Record Read Log

Changes are only half of what happens to data. The record read log records who has looked.

Where to find it

Architect Panel → Activity:

• Record Read Log — the reads themselves
• Activity Log — changes, kept separately

What a read entry holds

• Datastore — what was read.
• Record IDs and a row count — which records, and how many.
• Context — the kind of access it was.
• Identity — method, unique ID and domain, as with changes.
• IP address and timestamp.

Why it is separate

Volume, mostly. A system generates far more reads than writes, and mixing them would bury every change in a haystack of routine lookups. Keeping them apart means the change log stays readable and the read log can be retained on its own terms.

They also answer different questions. Changes answer "how did this get like this". Reads answer "who has seen this" — which is the question that arises in data protection, in HR matters, and any time information about a person has evidently travelled further than it should.

Row counts matter as much as row IDs

An entry recording that one record was read is routine. An entry recording that eleven thousand were read in one operation is a different event entirely, and it is the shape that indicates bulk extraction rather than somebody doing their job.

When reviewing, sort by row count before reading chronologically. The interesting entries are rarely the typical ones.

Context tells you how

The same record read on screen, returned by an API call, or included in an export are different events with different risk. The context field is what separates them, and it is what turns "this account read the customer table" into a statement you can act on.

Read logging is a decision

Logging reads has a cost in volume, so it is applied where it is warranted rather than universally. Turn it on for the datastores holding information about people, or anything where "who has seen this" is a question you might have to answer to somebody else.

Turning it on for everything produces a log nobody reviews, which provides the storage cost of assurance without the assurance.

Tell people it is on

Read logging is much more effective as a known control than as a hidden one — most inappropriate access is casual curiosity, and casual curiosity stops when people know access is recorded. It also belongs in your privacy notice: you are processing data about your staff's activity.

Worked example

A council enables read logging on its resident records. A monthly review sorted by row count shows the usual pattern of single-record lookups, and one entry where an account read 4,000 records through an export in a single afternoon. It turns out to be a legitimate mailing extract that nobody had told the data protection officer about — which is a process problem found in five minutes rather than a breach found by a regulator.

Recommendations

• Enable it on personal data, not on everything.
• Review by row count first, then by time.
• Tell staff it is enabled — the deterrent is most of the value.
• Cover it in your privacy notice.