Software companies
Salesforce field history retention: preserve history before it disappears
By SourceX Editorial · Updated
Short answer
Salesforce field history retention is limited: standard tracking records changes only for fields an admin enabled, only from the day they were enabled, and only for the retention window Salesforce documents unless you add Field Audit Trail. To keep it, export the history objects with their record and user IDs on a schedule, before older entries age out.
Key takeaways
- Field history exists only for fields that were tracked, starting from the day tracking was turned on.
- History objects such as OpportunityFieldHistory and CaseHistory can be exported directly, with the IDs that link them to parent records.
- A recurring export, not a one-time pull, is what keeps history from aging out.
- The change trail is often worth more than the current record, because it shows how deals and cases actually moved.
- History contains business contact details and deal terms, so it needs privacy and confidentiality review before any reuse.
How long does Salesforce keep field history?#
Salesforce keeps field history for a limited retention window, and the exact limit and how it is enforced are set out in Salesforce Help for your edition. Older entries can be removed unless your org has Field Audit Trail, a paid add-on that archives history for longer under its own retention policy.
Two other limits matter as much as the window. Only fields an admin enabled for tracking have any history, and tracking is not retroactive, so a field switched on last year shows nothing from before then. Each object also caps how many fields can be tracked, which means someone chose some fields and skipped others.
Before planning an export, check three things in Setup: which objects have history tracking on, which fields are tracked on each, and whether your org has Field Audit Trail.
Which history records are worth preserving?#
The history records worth preserving are the ones that show how revenue and service work progressed: opportunity changes, case status moves and ownership changes. They sit in separate history objects, each linked to a parent record.
Each history row holds the parent record ID, the field, the old and new values, who made the change and when. That is enough to rebuild a timeline, as long as the parent records and users are exported alongside it.
| History object | What it records | Why it matters |
|---|---|---|
| OpportunityFieldHistory | Changes to tracked opportunity fields, with old and new values | Shows how amounts, close dates and next steps shifted |
| OpportunityHistory (stage history) | Stage, amount, probability and close date snapshots | Shows the path each deal took through the pipeline |
| CaseHistory | Status, priority, owner and other tracked case changes | Shows escalations, handoffs and time spent in each state |
| AccountHistory and ContactHistory | Tracked changes on accounts and contacts | Shows ownership, segment and lifecycle changes |
| History on custom objects | Tracked changes on objects your team built | Often holds the most product-specific workflow |
Steps to preserve field history before it ages out#
Preserving field history takes a recurring export of each history object, plus the parent records and user list that give it meaning. A single pull before a migration protects what exists that day; a scheduled one protects what would otherwise expire next.
Reports built on history report types are handy for spot checks but awkward for full extraction. Third-party backup products can automate the schedule; confirm they capture history objects and not only current records.
Keep the output format plain and consistent: one file per object per run, column names that match the API field names, and a short manifest noting the run date, the query used and the row count. A later reviewer can then prove that nothing was skipped or edited between runs.
- Inventory tracking: list every object and field with history tracking enabled, and note when each was switched on if anyone knows.
- Export history objects with Data Loader or the Bulk API, keeping parent ID, field, old value, new value, created by and created date.
- Export the parent objects and the user table in the same run, so IDs resolve to records and roles.
- Save picklist and stage definitions, since stage names and values get renamed over the years.
- Store files in company-controlled storage, append new runs rather than overwriting old ones, and log each run.
- Review tracked fields and enable tracking on fields that drive decisions but were never tracked, knowing history starts only from that day.
Why the change trail is the valuable part#
The change trail is the valuable part because a current Salesforce record shows only where a deal or case ended up, while history shows how it got there. An opportunity that moved from discovery to proposal, slipped its close date twice, dropped in amount and then closed tells a story the final record hides.
Case history adds the service side: when a case moved from new to escalated, who took ownership and how long it waited in each status. Joined with case comments and the linked engineering issue, it shows how a support team actually resolves problems, not just which problems it closed.
That sequence is what AI developers building sales and service agents look for: real decisions, in order, made by people doing the work. In the SourceX Enterprise Data Value Framework, preserved history strengthens human-generated signal, recency when exports stay current, and AI utility. History that has aged out cannot be rebuilt later.
What to check before reusing exported history#
Exported history needs a rights and privacy check before any reuse, because it records business contacts, customer names and deal terms. Old and new values in a contact field are personal information, and an amount change on a named customer's opportunity may be confidential under that customer's agreement.
Run this check on the exported files rather than inside Salesforce, so cleanup never touches the live org.
| Content in history | Risk | Typical handling |
|---|---|---|
| Contact names, emails and phone changes | Personal information | Remove or replace with placeholders |
| Account and customer names | Customer confidentiality | Replace with consistent pseudonyms |
| Amounts and pricing fields | Commercially sensitive | Group into ranges or exclude, depending on scope |
| Free-text fields such as next steps or descriptions | Names and details written in prose | Review and redact, or exclude |
| User IDs of your own staff | Employee personal information | Map to roles rather than names |
Illustrative: an IT director preserves CRM history before a migration#
Illustrative: a fictional vertical SaaS company that sells inspection software to property managers is moving from Salesforce to HubSpot. The migration plan maps current accounts, contacts and opportunities, and nothing else.
The IT director checks Setup, finds tracking on opportunity stage, amount and close date plus case status and owner, and confirms how far back each history object still reaches. Using Data Loader, the team exports the history objects, parent records, users and stage definitions, and keeps the files in restricted storage with a run log. The CRM switch goes ahead on schedule, and the pipeline and support history survives in a form that can still be joined, reviewed and assessed.
How SourceX approaches CRM history#
SourceX treats preserved CRM history as part of the Supply step of the SourceX five-step transaction: the fit check asks which objects were tracked and how far back exports reach, without receiving files. The Rights and Preparation steps then address customer contracts, business contact details and deal terms.
For each package that proceeds, the SourceX Evidence Packet records where the history came from, what was removed and who authorized release.
Frequently asked questions
Does Field Audit Trail replace exporting history?
No. Field Audit Trail extends how long Salesforce keeps history inside the platform, which helps audits and compliance. It does not give you a copy outside Salesforce, so if the contract ends or you migrate, you still need an export. Many teams use both: the add-on for in-platform retention and exports for independence.
Can we recover history that has already aged out?
Usually not from Salesforce itself. Check whether a backup tool, a data warehouse sync or an earlier migration project captured history objects, since those copies are often the only remaining source. Going forward, a scheduled export prevents the same gap.
Is Chatter feed tracking the same as field history?
No. Feed tracking posts changes into Chatter feeds for collaboration, and those posts follow their own rules. Field history lives in history objects and is the more structured record. If your teams relied on feed tracking, check whether it captured changes that field history did not, and export both if so.
Do we need to export history if we are not migrating?
Yes, if the history matters to you. Retention limits apply whether or not you change systems, so a stable org still loses older entries over time. A recurring export keeps the full trail available for audits, analysis and any later decision about licensing.
Which team should own the history export?
Usually the Salesforce admin team runs it and IT or data engineering stores it, with sales and service operations deciding which fields matter. Record the owner in your retention schedule so the export keeps running through staff changes, org merges and admin turnover.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.