Who Changed That Record? Building a Real Audit Trail in Salesforce

A nonprofit I work with asked a question every organization eventually asks, usually right before a funder review: “If someone changes a service record, can we see who changed it and what it said before?”

The answer in Salesforce is yes — with two catches that surprise almost everyone. First, the audit trail only exists for fields someone explicitly chose to track, starting from the day they chose. Second, for a lot of objects, Salesforce will not let you build a report on it. The data is right there in the database, fully queryable, and the report builder simply has no door that opens onto it.

How Field History Tracking actually works

Every major object — Contacts, Opportunities/Donations, custom objects, and newer standard objects — has a Set History Tracking button under Object Manager → Fields & Relationships. You pick up to 20 fields. From that moment on, any change to a tracked field writes a history row: who, when, old value, new value.

Three fine-print items worth knowing before you promise an auditor anything:

1. Nothing is retroactive. History starts accruing when tracking is enabled, never before. If it’s off today, the best day to turn it on was last year; the second-best day is today.
2. It may already be on. In the org that prompted this note, tracking had been quietly enabled since the previous year — there was already a full audit trail nobody knew about. Check before you assume.
3. Long text fields are tracked as “edited” only. Salesforce records that a notes field changed and who changed it, but never stores the old and new text. For sensitive narrative fields, that’s arguably a feature.

Where you can actually see it

The simple, reliable view is the History related list. Edit the object’s page layout, drag “History” from the Related Lists palette onto the page, and save. Every record now shows its own change log — date, user, field, old value, new value. For “an auditor wants to spot-check these records,” this is usually the whole answer.

The reporting wall

For an org-wide view — “show me every change across all records last quarter” — you’d naturally reach for a report. Sometimes that works: some classic objects (Accounts, Opportunities) ship with a standard “History” report type, and custom objects generate one when tracking is enabled.

But many newer standard objects have no history report type at all, and the history table doesn’t appear in the custom report type wizard either — not as a primary object, not as a related one. This isn’t a configuration you’re missing. The history data for those objects is simply not reportable, period, and no amount of clicking will change it.

What remains is the API: the history table (it’s named after the object, e.g. InteractionSummaryHistory) responds normally to queries. So the org-wide audit view becomes an export — anyone comfortable with a SOQL query or Data Loader can pull date, user, record, field, old and new value into a spreadsheet in a couple of minutes.

If the people who need it aren’t query-comfortable, that export can be wrapped in a button: a small screen flow that takes a date range and hands back a CSV file. (One implementation note if your admin builds this: Flow cannot write the file contents itself — ContentVersion.VersionData rejects text from Flow — so the file creation needs a few lines of Apex behind the flow. Budget an hour, not a day.)

The five-minute version

1. Object Manager → your object → Fields & Relationships → Set History Tracking. Is it on? Are the right fields checked?
2. Drag the History related list onto the page layout.
3. Try New Report and search ” History.” If a report type exists, build it and you’re done. If it doesn’t, it never will — plan on an export instead, and tell your auditor the per-record view plus an export covers the requirement. It does.

The day a funder, a board member, or a departing-staff situation makes someone ask “who changed this?” — that’s the wrong day to be turning tracking on. It’s two clicks. Do it this week.