The short answer: three different tools answer three different questions. Setup Audit Trail tells you who changed the configuration. Field history tells you who changed the data, but only on fields you turned tracking on for before the change happened. Debug logs tell you which automation did it, and only if you can reproduce it. If the field wasn’t tracked and the change was last month, the answer does not exist anywhere in your org, and no support case will recover it.
Pick the right tool first, or you’ll waste an hour
| What you’re asking | Tool | Where | How far back |
|---|---|---|---|
| Who edited this validation rule / field / profile? | Setup Audit Trail | Setup → View Setup Audit Trail | 20 entries in the UI, 180 days in the download |
| Who changed this record’s Stage from Negotiation to Closed Lost? | Field history tracking | The object’s History related list, or the <Object>History object |
18 months in the org, 24 via the API, and only if tracking was already on |
| Which flow, trigger, or rule wrote that value? | Debug log | Setup → Debug Logs, trace flag on the user | Forward only — you must reproduce it |
| Who ran that report or pulled that export? | Event Monitoring | EventLogFile / Event Monitoring Analytics |
Licensed add-on; not in every org |
Read LastModifiedById and LastModifiedDate on the record first. Always populated, and it splits the problem in half: if the timestamp matches when the weirdness was reported, you’re chasing a data change. If it doesn’t, something upstream changed (a formula, a rule, a layout), and you want the audit trail.
Setup Audit Trail: metadata only, and it records the fact, not the diff
Setup → Quick Find → View Setup Audit Trail shows the 20 most recent setup changes. Click Download for the last 180 days as CSV — the only version worth using, because 20 rows is nothing in an org with three admins and a CI pipeline.
The columns you care about are Date, User, Action (the human-readable description), Section, and Delegate User. That last one is the tell for “I didn’t touch it” — if someone used Log In As, the Delegate User column names them while the User column names the account they borrowed.
It is also a queryable object, which makes it far more useful than the download UI:
SELECT CreatedDate, CreatedBy.Name, Section, Display, DelegateUser
FROM SetupAuditTrail
WHERE CreatedDate = LAST_N_DAYS:7
ORDER BY CreatedDate DESCTwo limits to be honest about. It records that a validation rule changed, not what it said before — no diff, no previous version, no rollback. And a deployment lands as one large block of entries under whichever user the deployment authenticated as, which tells you the release did it and nothing about who wrote the change.
Field history tracking: prospective, capped, and lossy on long fields
Turn it on at Setup → Object Manager → [Object] → Fields & Relationships → Set History Tracking. Check the object-level box, then tick the individual fields. History then appears in the record’s History related list and in a queryable history object — AccountHistory, Opportunity_Line__History, and so on.
SELECT Field, OldValue, NewValue, CreatedById, CreatedDate
FROM OpportunityHistory
WHERE OpportunityId = '006XXXXXXXXXXXXXXX'
ORDER BY CreatedDate DESCNow the gaps, in the order they bite people:
It only starts when you turn it on
This ends most investigations. Tracking is not retroactive. Enabling it today tells you nothing about yesterday. Every “who changed this?” question about an untracked field is unanswerable, and the only useful response is to enable tracking so the next one isn’t.
Twenty fields per object
Without Field Audit Trail you get 20 tracked fields per object. On a 300-field Opportunity that is a real budget: spend it on the fields that drive money, forecasting, and access, not the ones people complain about loudest.
Retention runs out
Salesforce retains field history for up to 18 months in the org and up to 24 months through the API. Field Audit Trail, a paid add-on, extends that considerably and archives rather than deletes. If your compliance answer is “we keep seven years of change history,” field history tracking on its own is not that answer.
Long fields record the event, not the values
For fields longer than 255 characters, history records that an edit happened and when. The old and new values are not stored. The row on a long text Description tells you someone changed it and nothing about what it said. That surprises people badly mid-dispute.
Derived fields have no history at all
Formula and roll-up summary fields aren’t offered on the Set History Tracking page, because they have no stored value to change. If a formula’s output flipped, the change is in one of its inputs, or in the formula itself, which is a Setup Audit Trail question. Track the inputs.
The automation gap: the log names a person, not the flow
This is the part that sends admins in circles. When a flow, process, or trigger writes a field, the history row and LastModifiedById generally name the user whose action set the automation off, not the automation. Jane clicked Save on an unrelated field, a flow recalculated Stage, and the history says Jane changed Stage. She will tell you she didn’t, and she’ll be right.
Two variations. If the triggering user is inactive, the org’s default workflow user appears instead. Setup → Process Automation Settings names it. And some contexts really do run as Automated Process, including Apex triggers on platform events, so changes attributed to that user usually mean an event-driven integration rather than a person.
Nothing in field history names the flow. To get that, you need a log.
Debug logs: the only tool that names the automation
Setup → Debug Logs → New, add a trace flag on the user who can reproduce it, and set the Workflow and Validation categories to INFO at minimum, FINER in an org with layers of automation. Reproduce the save, then search the log for FLOW_ELEMENT, VALIDATION_RULE, and CODE_UNIT_STARTED to get the ordered list of what ran.
The constraints matter. Each log is capped at 20 MB and older lines are dropped when it exceeds that, so a chatty org loses the start of the transaction, which is exactly where the before-save flow lives. Monitoring logs are kept seven days, system logs 24 hours. Generate more than 1,000 MB in a 15-minute window and your trace flags switch off for 15 minutes. Log one user and one reproduction, not the whole team all afternoon.
When none of them answers it
Accept that this occurrence is unrecoverable, then make the next one cheap. Three moves, in the order I’d do them.
Enable tracking on the disputed field now. Field history doesn’t count against data storage, so it costs nothing and turns an unanswerable question into a five-second query next quarter.
Make the automation self-documenting. Where a flow writes a contested field, have the same flow stamp a companion text field: Set by Opportunity_Stage_Sync on {!$Flow.CurrentDateTime}. The tradeoff is real: an extra field, one more thing to maintain, and a value that lies if someone edits the flow and not the stamp. I still take it on the two or three fields per org that cause the most arguments, because a stamp outlives every retention window.
Frequently asked
Can I recover history for a field I never tracked?
No. There’s no hidden store to enable retroactively and no support process that retrieves it. The only exception is indirect evidence: a Chatter feed post if feed tracking was on, a report snapshot, an old data export, or a sandbox refreshed before the change.
Why does history show a user who insists they didn’t change it?
Almost always because automation ran in their context. A flow or trigger fired off their save and is recorded under their name. Reproduce the save with a debug log on that user and read the Workflow and Validation entries to find the actual writer.
Does field history tracking consume data storage?
No. Field history data doesn’t count against your storage limits. The reason to be selective is the 20-fields-per-object cap and the noise in the History related list, not storage cost.
How do I find out who deleted a record?
None of these three tools does that well. Check the Recycle Bin first, since a deleted record still shows its last modifier. Setup Audit Trail won’t have it. Deleting data isn’t a setup change. Mass deletions and API-driven deletes are an Event Monitoring question.
Reference: Monitor Setup Changes with Setup Audit Trail, Field History Tracking Overview, Field Audit Trail, and Considerations for Field History Tracking, Salesforce Help; Debug Log, Salesforce Apex Developer Guide.
