Systems and records
How far back does Salesforce field history go?
By SourceX Editorial · Updated
Short answer
Salesforce field history goes back only as far as its retention window, and only to the day tracking was switched on for each field. Standard field history tracking keeps a limited rolling window for a capped number of fields per object; Field Audit Trail, a paid add-on, archives history for years. Anything older is gone unless it was exported.
Key takeaways
- Field history starts the day tracking is enabled for a field; earlier changes are never captured.
- Standard tracking keeps a rolling window of months for a capped number of fields per object; check Salesforce's current limits for your org.
- Field Audit Trail moves older history into the FieldHistoryArchive big object and keeps it under a retention policy you define.
- Archived history is read through API queries with restricted filters, not through standard reports.
- Without Field Audit Trail, schedule exports of the history objects before rows age out.
Standard tracking versus Field Audit Trail#
Standard field history tracking and Field Audit Trail answer the same question at different depths. Standard tracking comes with many Salesforce editions and keeps a short rolling window; Field Audit Trail is a paid add-on, often bought as part of Salesforce Shield, that keeps much longer history for more fields.
Salesforce publishes the exact retention periods and field caps in its help documentation, and they can differ between what the interface shows and what the API returns. Read the current article for your edition before you promise anyone a date range.
| Question | Standard field history tracking | Field Audit Trail |
|---|---|---|
| Retention | A rolling window measured in months | Measured in years, set by a retention policy within Salesforce's maximum |
| Fields per object | A capped number of tracked fields | A higher cap than standard tracking |
| Where history is stored | History objects such as AccountHistory, CaseHistory and OpportunityFieldHistory | Recent rows in the same objects, older rows in the FieldHistoryArchive big object |
| How you read it | Related lists, history reports and standard queries | API queries against FieldHistoryArchive with restricted filters, or asynchronous queries |
| Licensing | Included in many editions | Paid add-on |
| Old rows | May be removed under Salesforce's retention policy once outside the window | Kept until your retention policy removes them |
What field history records, and what it never did#
Field history records a change to a tracked field: the record, the field, the old value, the new value, the user who made the change and the time. It covers only fields someone chose to track, and only from the date tracking was turned on.
Opportunities add a wrinkle. Alongside field history, Salesforce keeps a separate opportunity history that records changes to fields such as stage, amount and close date, which many pipeline reports rely on. Check both objects when you assess how far back pipeline history goes.
- No backfill: enabling tracking today captures nothing about changes made before today.
- Selected fields only: untracked fields leave no trace, which is why the choice of fields matters.
- Long text: for some long and rich text fields, history notes that a change happened without storing the values.
- Calculated fields: formula and roll-up summary fields are calculated rather than edited, so they are not tracked.
- Edits, not views: field history does not show who opened or read a record.
How to check how far back your org goes#
Checking how far back your org goes takes a short audit of tracked fields, history objects and licenses, and an admin can run it without exporting anything.
The answer is usually uneven. Cases may have a long history because support turned on tracking early, while opportunities rely on stage history and some custom objects have no tracking at all.
- In Setup, open each key object in Object Manager and review Set History Tracking to see which fields are tracked.
- Query each history object for its oldest created date to see where history actually starts.
- Check installed licenses for Field Audit Trail or Salesforce Shield, and whether a retention policy is defined.
- Ask whether anyone already exports history objects to a warehouse or backup tool, and from what date.
- Write down the gaps: objects without tracking, fields added later and periods before tracking began.
How to keep history longer without Field Audit Trail#
Keeping history longer without Field Audit Trail means copying history objects out of Salesforce on a schedule, before rows age out of the window. The options differ mainly in effort and in how easy the history is to query later.
Whichever route you choose, store the record ID, field name, old and new values, user ID and timestamp, and keep a user lookup so that changes by former employees still resolve to a name and role.
| Option | What it keeps | Trade-off |
|---|---|---|
| Scheduled API export of history objects | Every tracked change, appended to your own store | Needs a job owner and monitoring |
| Data warehouse or replication tool | History tables beside current records | History from before the connection must be backfilled while it still exists |
| Backup product | Point-in-time copies, sometimes including history objects | Confirm history objects are covered and how restores work |
| Reporting snapshots | Values of chosen fields at set intervals | Shows states at intervals, not each change |
| Data Export Service from Setup | Zip files of CSVs for selected objects, every 7 days on Enterprise, Performance and Unlimited or every 29 days on Professional and Developer | Easy to forget, easy to leave history objects unselected, and a missed run waits for the next window |
Why change history matters beyond audit#
Change history matters beyond audit because it is the sequence of decisions on each account, opportunity and case. Status changes, owner changes, escalations and reopened cases show how work moved, not just where it ended.
That sequence is what revenue teams use to study sales cycles, what acquirers test in diligence, and what AI developers look for in operational records. A case that shows only its final status says little; a case with its status changes, owner handoffs and linked comments shows how a problem was diagnosed and solved.
Choose tracked fields with that use in mind. Status, owner, priority, stage, close date and escalation flags usually tell the story of a record; cosmetic fields rarely do. Because the field cap forces a choice, review the tracked list whenever processes change, so the fields that capture decisions are not crowded out by fields nobody reads.
Illustrative: a vertical software company checks its CRM history#
Illustrative: a fictional mid-sized vertical software company has run Salesforce for many years. Ahead of a board discussion about its data, the CTO asks how far back case and opportunity history goes.
The admin finds that case status and owner changes have been tracked for years, but only the recent window survives under standard tracking. Opportunity stage history exists, though nobody had checked its depth. The company has never licensed Field Audit Trail.
The CTO sets up a scheduled export of every history object to the company's warehouse, with a user lookup. Older status changes are gone, but case comments and emails still show how problems were solved, and from now on every tracked change is kept.
How SourceX looks at Salesforce history#
SourceX looks at Salesforce history as part of a broader CRM and support record family, assessed through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The fit check needs only metadata, such as which objects are tracked, how far back history goes and whether cases link to comments and outcomes.
If a package proceeds, Preparation removes personal and confidential details such as contact names and email addresses, and the SourceX Evidence Packet records how the history was exported, the licensing rights and permitted use, the privacy record and release authorization.
Frequently asked questions
Does enabling field history tracking capture past changes?
No. Tracking records changes from the moment it is enabled for a field, and field history cannot be backfilled. Older context may survive elsewhere, such as in case comments, emails, activity records, a backup or an earlier export, so check those sources before assuming it is gone.
Can we recover field history that has aged out?
Usually not from Salesforce itself. Once history falls outside the retention window and is removed, it survives only if it was exported, captured by a backup or replication tool, or archived through Field Audit Trail. Check every system that may have copied it.
Is Field Audit Trail worth buying just for an archive?
It depends on how often people need to query old changes inside Salesforce. If history is needed mainly for occasional analysis or diligence, a scheduled export to your own warehouse may be enough. Compare the add-on's cost with the effort of running and monitoring an export job.
Do custom objects have field history too?
They can, once history tracking is enabled on the object, and their history is stored in an object of its own. The same retention window and field cap apply, so include custom objects in your audit rather than assuming only standard objects matter.
Should field history be part of a CRM migration?
Yes, at least as an archive. Most migrations load current records into the new CRM and leave history behind. Export the history objects with record IDs and a user lookup before the old org is closed, so change sequences can still be read later.
Sources
- Salesforce's Data Export Service allows a manual export every 7 days in Enterprise, Performance and Unlimited Editions, while Professional and Developer Editions can generate backup files only every 29 days. Source
- The Data Export Service delivers zip files of CSVs, split into multiple files when large. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.