Why an immutable audit trail matters
PL
Priya Lall · Compliance Officer
"Legal is asking who changed the value on this contract, and when. Our compliance review is in two weeks, and I need a real answer — not a guess based on who usually touches that record."
Without a system-level audit trail, "who changed this and when" becomes a slow, unreliable investigation involving emails, memory, and guesswork.
Business outcome
Any change to any record can be reconstructed and attributed on demand — compliance reviews become a lookup, not an investigation.Two different logs, two different jobs
| Log | Purpose | Lifespan |
|---|---|---|
| Audit Log | Permanent record of every CREATE / UPDATE / DELETE, with before/after values and who did it | Immutable, append-only, kept indefinitely |
| Debug Log | Technical execution trace — validation, workflow steps, formula evaluation — for one specific operation | Transient; intended for troubleshooting, can be cleared by an admin |
What's captured on each action
beforeJson is null on CREATE (nothing existed before); afterJson is null on DELETE (nothing exists after). Every other combination captures both states.Trace a field change back to its source
Make a changeOpen any Opportunity and edit its Amount field, then save.
Open the Audit LogSetup → Audit Log → filter by object = Opportunity.
Inspect the entryConfirm it shows the before and after Amount values, the username who made the change, and the timestamp.
Check record-level historyOpen that same Opportunity's detail page and view its change history directly.
Review a Debug Log (optional)Setup → Debug Logs — open a recent session to see the validation and workflow trace for that same save.
Test what you learned
1. What is
beforeJson set to on a CREATE audit entry?Null — there was no prior state
A copy of the default field values
2. Can an admin clear Debug Logs?
Yes — they're transient troubleshooting data, not permanent records
No — they're immutable just like Audit Logs