Audit Log
The Audit Log is a tamper-evident record of who did what in the app. It exists because this system writes to production Salesforce, changes pricing and mappings, and manages user access — activity that a serious operation needs to be able to reconstruct and trust after the fact. The log is designed so that history cannot be quietly altered or deleted without detection.
How it fits
What is recorded
| Category | Examples |
|---|---|
| Authentication | Sign-ins, sign-outs, and access denials |
| Administrative changes | User and role changes, pricing edits, product mappings, form structure changes |
| Business activity | Inspection submissions, proposal finalizations, price overrides |
| Salesforce writes | Every write to Salesforce, recorded before and after, with automatic reconciliation of operations that were interrupted mid-flight |
Recording business activity before and after each Salesforce write is what lets the trail show not just that something was attempted, but what the state was on either side of it — and to reconcile writes that were interrupted rather than leaving a gap.
The Audit Log console
Level 5 administrators get an Audit Log console (Admin → Audit) that presents the trail as a live timeline:
- A chronological feed of sign-ins, administrative changes, access denials, and business events.
- Filtering to narrow to an actor, a category, or a time range.
- A detail view for each event.
- Built-in cryptographic verification tooling that checks the trail for signs of alteration.
How tamper-evidence works
The point of the Audit Log is not just that events are written — it is that they cannot be rewritten unnoticed. Two mechanisms provide that guarantee.
- Signed events — audit entries are cryptographically signed and chained, so altering or removing an entry breaks the chain in a way the verifier can detect.
- Daily anchors — a cryptographic anchor for each day is written to immutable storage. Because the anchor is fixed once written, it becomes a checkpoint that any later tampering with that day’s history would contradict. The verification tool compares the live trail against the anchors and reports any deletion or alteration.
The event catalog itself is frozen: the set of event types is fixed and versioned, so the meaning of a recorded event does not drift over time.
Access
The Audit Log console is a Level 5 administrative surface. The underlying trail is protected at the database layer with row-level security and monthly partitioning, independent of the UI gate, so access to audit history does not depend on an application check alone.
Pitfalls
- Do not treat the Audit Log as an operational dashboard; it is a forensic record. Use the Operations panel for day-to-day workflow monitoring.
- Do not expect to edit or remove an audit entry. The design goal is precisely that entries cannot be silently changed; corrections are new events, not edits.
- Do not read a failed verification as noise. A verifier that reports alteration is doing its job — escalate it.
Related pages
- Admin Tools covers the other Level 4 and Level 5 administrative surfaces.
- Roles and Permissions explains the Level 5 gate on the Audit Log console.
- Salesforce Integration explains the Salesforce writes the trail records before and after.