Capabilities · Audit trails

Know what changed and who changed it.

A customer disputes a price. A manager asks why a booking was cancelled. If the system only stores the current value, nobody can answer without guesswork.

One question, with and without history.

Current value only

"It just shows today's price."

Take a hypothetical property sales system where a unit's price was revised last week. The record shows the new figure. Nobody can say what it was before, who changed it, or whether the customer was quoted the old one.

  • Answers depend on someone's memory
  • Disputes turn on screenshots
  • Mistakes can't be traced to a cause
With an audit trail

The full story on the record

The same unit shows the previous price, the new price, the person who changed it, the time, and the reason they entered when they saved it.

  • Old and new values side by side
  • Actor and time on every change
  • A reason captured as it happened
Anatomy of a record

What a useful entry holds.

The detail depends on the event, but most entries worth keeping answer these.

WhatThe event itself: a price change, an approval, a status move, a permission change, an export.
Before and afterThe previous value and the new one, for each field that changed.
WhoThe person, or the automated process, that made the change. Automated updates are marked so they're never mistaken for a person's decision.
WhenThe exact time, set by the system rather than typed in.
WhyA reason, required for events where you'll need one later, such as overriding a price or reversing a payment.
WhereThe record it belongs to, so the history appears on the booking, order or request itself.

Log what matters, not everything.

Recording every click sounds safe and produces noise nobody reads, so the entry you need gets buried when something goes wrong. We agree with you which events need a history, who can review it, and how long records are kept. That list usually centres on money, approvals and access.

Readability matters as much as coverage. An entry that says "field 14 updated" helps nobody. Entries should name the record, the field and the person in words a manager can follow, and the people allowed to review them should be able to search by record, by person or by date.

A timestamp alone rarely explains a decision. Capture the context when it happens.

When people open the history.

Customer dispute

"I was quoted less."

Support opens the order, sees the price change and its reason, and replies with facts instead of apologies.

Month-end review

Unusual reversals

Finance checks refunds and reversals made outside the normal rules, with the person and reason on each one.

After a mistake

Tracing a bad update

A bulk import overwrote some records. The trail shows which ones and what they held before, so they can be put right.

Access check

Who granted that?

An admin finds a user with rights they shouldn't have, and sees when and by whom their role was changed.

Before you add an audit trail.

Does an audit trail prove compliance?

It supports your controls, but it isn't a compliance certificate. Specific regulatory requirements need their own assessment, and the trail is then designed to meet what that assessment asks for.

Will it show changes the system made on its own?

Yes. Scheduled jobs, integrations and automated rules are recorded too, labelled as such, so nobody mistakes an overnight sync for a colleague's edit.

Can people edit or delete the history?

Regular users can't. We agree with you who may view the full history, and entries are kept for the retention period you set.

Can we add one to a system we already run?

Often, for the events that matter from that point on. History from before it was added can't be recreated, which is a good reason to plan it early, whether in a new build or a software takeover.

Contact

Which change would you need to explain?

Tell us the question your history must answer, and we'll work back to the events worth recording.

Message on WhatsApp