Read the audit trail
Find out what changed, when, and who changed it, and know how far that answer can actually be trusted.
Before you start
Know what is in this record and what is not.
In: every insert, update and removal of a tracked record made through PTRS by a signed-in person, with the values before and after captured, plus every specific action a screen explicitly logs.
Not in: anything done by a scheduled background process. Nothing without a signed-in person's own request behind it is captured here at all, which is every one of PTRS's twelve scheduled jobs and both of its background workers.
Know that this record is scoped to your own organisation. All four audit actions add that limit by hand, because the record type itself has no automatic organisation boundary the way most of PTRS does.
Steps
1. Open the audit trail
The heading is Audit Trail with the subtitle "Tamper-evident SHA256 hash-chain log of all system actions." Six columns: Timestamp, Action, Entity, Details, User, IP Address.
The count on the right, "N total entries," is a genuine count over the whole filtered set, not just the rows on screen. Seen in PTRS
2. Narrow it with search and dates
These three are sent to PTRS and work across the whole log.
| Control | What it matches |
|---|---|
| Search | The written description, the resolved person's name, or the record's own id, ignoring case, starting shortly after you stop typing |
| Start date | Entries at or after midnight on that day |
| End date | Entries at or before the last second of that day; the end day is fully included |
3. Do not rely on the Action and Entity dropdowns
These two filter only the fifty rows already loaded, in your own browser, and build their own choices from those same fifty rows. So:
An action that does not happen to appear on the page you are viewing is not even offered as a choice.
Choosing one shows its rows on this page only, not across the log.
The total in the corner keeps describing the whole, unfiltered log regardless.
PTRS can filter by record type on its own side, and this screen never asks it to. Use the search box instead; it genuinely reaches PTRS.
4. Read a row
| Column | What it is |
|---|---|
| Timestamp | When the change was saved, in your own browser's timezone |
| Action | Insert, Update or Delete for a tracked change, or Activity for anything a screen logged explicitly |
| Entity | The kind of record: a member, an incident, a note |
| Details | For an Activity row, the sentence written at the time. Empty for the three tracked actions |
| User | The person's name if it could be resolved, otherwise their raw sign-in identity |
| IP Address | Where the request came from |
Activity is not a defect in your own data. Every explicitly logged action is saved with the fixed word Activity in this column, and its real, specific name is written into the Details sentence instead, because there is nowhere else in the saved record for it to go.
Four action names get their own colour: Insert, Update, Delete and Activity, exactly what PTRS itself ever writes. A handful of other action names exist only in a development copy's own starter data, and none of those get a colour, so on a development copy most rows show up grey.
5. Press Verify Integrity if you need the chain checked
The button runs the check on demand; it does not run automatically when the page loads.
The result appears beside the button as either "N entries verified" in green, or a message naming the specific entry where the chain broke, in red.
Reading the verification result
A green result means what it says, for the parts of a row the check actually covers: no entry in your organisation's own record has been removed, inserted, reordered, or had its record type, record id, action or timestamp changed.
A red result does not necessarily mean tampering. Three ordinary conditions produce it too.
| Condition | Why | How to tell |
|---|---|---|
| More than one organisation shares this installation | The record is written as one continuous sequence across all of them and checked one organisation at a time. The check breaks on the first entry that follows another organisation's last one | It fails very early, and the verified count is small |
| This is a development copy of PTRS | The starter data built into it was written directly, without going through the same process real activity goes through | It reports a verified count of zero and breaks on the very first entry |
| Two entries were written by the same save | Every entry written in one save shares an identical timestamp, and both the writing and the checking rely on that same timestamp for order | It breaks on an entry that has others sharing its exact timestamp |
What a red result should trigger is a closer look, not an immediate conclusion. Check the entry it names and the ones around it, and check whether either of the first two conditions above applies to your own installation.
See the audit hash chain for exactly what this check covers and what it does not.
Result
You have found the change, or established that it genuinely is not in this record, which, for anything a scheduled process did, it never will be.
What this does not do
Common errors
| What you see | Why | What to do |
|---|---|---|
| An access-denied message naming the audit trail | You hold a Staff account. The wider check lets you reach the address; the screen's own check does not include Staff | Correct. The actual rule behind it refuses Staff too |
| A message saying the audit trail failed to load | You hold a read-only account. The screen's own check admits it and the actual rule does not | A read-only account satisfies no rule anywhere in PTRS |
| A message saying your account is not yet assigned to an organisation | Your account record has no organisation. Every audit action refuses without one | See how a person becomes a PTRS user |
| Every row says Activity | Expected for anything explicitly logged. The specific action is inside Details | Not applicable |
| The User column shows a long code instead of a name | No account record's sign-in reference matches that entry, usually an account created outside the invitation process | Check the user list in Administration |
| An action you know happened is not in this record | Either a scheduled process did it, or it was only a read; only inserts, updates, removals and explicitly logged actions are captured | Not applicable |
| Verify Integrity reports a break on a development copy | The starter data has no chain to verify | Expected. See above |
| A message saying no entries were found, with a non-zero total | The Action or Entity dropdown is filtering the current page and matched nothing on it | Set both back to All and use search |
Related
Checked against PTRS on 7 September 2026.