There’s a moment in the life of every growing Salesforce org where a compliance officer, an external auditor, or a lawyer sends the same message: “Can you produce a history of every change made to this field on this record over the last seven years?”
If you set up Field History Tracking in 2019 and never revisited, the answer is: “We can show you the last 18 months.” That answer doesn’t satisfy an auditor. It doesn’t satisfy a regulator. And the remediation — retroactively building a long-retention audit trail — is an expensive, imperfect project that usually ends in “we just don’t have that data.”
This is the single most consequential Salesforce architecture decision nobody talks about. Here’s how to get it right.
The Two Options, Side by Side
These numbers come straight from the Salesforce Field Audit Trail Implementation Guide and the Field Audit Trail help documentation. They are the decision inputs — not estimates.
The FieldHistoryArchive Big Object
This is the architecturally interesting part. Field Audit Trail does not extend standard Field History storage — it archives into a Big Object called FieldHistoryArchive. Per the implementation guide:
- Records that would otherwise be purged after 18 months are instead moved to the archive
- The archive supports the retention policy you configure per object (up to 10 years)
- Querying the archive uses Async SOQL, not standard SOQL — so your reporting patterns change
- The archive is separate from standard data storage and does not consume your data storage allocation
Big Objects are designed for hundreds of millions to billions of records. That is what field-history retention across a 10-year window can easily produce for a busy object. Standard field history is stored in regular object tables and would blow up your data storage long before you hit 10 years.
The Regulatory Decision Matrix
If your org is not subject to a specific retention requirement, standard Field History Tracking is genuinely enough. Don’t over-buy Shield because “compliance sounds important.” Use the 18 months as a prompt to revisit the decision as your regulatory posture evolves.
If your org is subject to SOX, HIPAA, GDPR with a specific consent-audit retention requirement, or any industry-specific regulation with a multi-year retention requirement — Field Audit Trail becomes architecturally mandatory. The remediation cost of not having the history, when asked for it, dwarfs the Shield licensing fee.
The Cost Conversation
Shield is typically sized as a material percentage of your total Salesforce spend. The exact number is commercial and varies by customer, edition, and negotiation. What matters for the architecture decision is:
- Shield is a bundle. It includes Platform Encryption, Event Monitoring, and Field Audit Trail. If the org needs any two of those, the economics of FAT become much more attractive.
- The incremental cost of enabling FAT after Shield is purchased is zero. It’s a policy configuration, not a license gate.
- The cost of having to retroactively build compliance evidence is significant. External audit firms, remediation consultants, and a rushed project schedule — that number routinely exceeds the Shield fee.
The budget question is not “can we afford Shield?” It is “can we afford the scenario where an auditor asks for 7 years of change history and we can produce 18 months?” Phrased that way, Shield is insurance, not overhead.
The Fields You Should Audit
When you move to FAT, you don’t automatically track everything — you configure retention per object and select which fields. A practical framing:
| Category | Examples | Audit? |
|---|---|---|
| Financial fields | Amount, CurrencyIsoCode, Billing_Terms__c | Yes, always |
| Status/lifecycle | StageName, Status, Approval_Status__c | Yes, always |
| Regulated data | Social_Security_Number__c, Medical_Condition__c | Yes, always |
| Ownership | OwnerId | Yes for compliance-relevant objects |
| Relationships | AccountId, ContactId on regulated records | Yes |
| Notes / descriptions | Description text fields | Usually no — too noisy |
| System timestamps | CreatedDate, LastModifiedDate | Already tracked — no |
The 60-field limit per object means you have to be deliberate about it. Don’t check every box. Start with the fields a regulator or auditor would realistically ask about.
A Real-World Migration
How to move from FHT to FAT without losing history
Step 1 — Before enabling Field Audit Trail, export your existing 18 months of Field History. You can do this via Data Loader or an Apex batch job against the <Object>History tables. Keep this export — it’s the pre-migration baseline.
Step 2 — Enable Field Audit Trail on the objects and fields you care about. Configure retention policies per the official Field Audit Trail Setup guide.
Step 3 — From the enable-date onwards, new changes accumulate in FieldHistoryArchive at the retention policy you set (1-10 years). Pre-existing history migrates per Salesforce’s documented behaviour.
Step 4 — Build your compliance reporting against FieldHistoryArchive via Async SOQL. Your 18-month-and-older queries may need a union with the exported baseline until the archive has a full retention period of its own data.
Problem: A biotech client hit their first serious audit four years into their Salesforce deployment. The auditor asked for change history on their clinical-trial-related Opportunity records back to the beginning. FHT had 18 months. The 2.5-year gap was unrecoverable, and the remediation project cost roughly 3x what Shield would have cost annually for the preceding four years.
Fix: They now have FAT on every regulated object with 10-year retention, plus an auto-review at every quarterly compliance meeting of which new fields should be added.
Common Pitfalls
Three mistakes I see repeatedly
1. Enabling FAT without designing the retention policy. FAT defaults are not “10 years on everything” — you must set the policy per object. Without explicit setup, you can end up with FAT enabled but retention policies that don’t meet your compliance need.
2. Querying FieldHistoryArchive with standard SOQL. It’s a Big Object. Use Async SOQL. Standard SOQL either returns nothing useful or errors out. This trips up even experienced developers.
3. Assuming FAT retroactively extends history. Enabling FAT does not recover data already aged out of the 18-month FHT window. The 18 months you had becomes the baseline, and new changes from that point forward accumulate in the archive.
Where the Official Docs Live
- Field Audit Trail Implementation Guide (Spring ‘26, v66.0) — the authoritative PDF
- Field Audit Trail help topic — conceptual overview
- Salesforce Shield overview — licensing bundle context
Read the Implementation Guide end-to-end before configuring. It’s the document that keeps you from a bad retention policy you discover only at audit time.
If your compliance officer asked tomorrow for a change history on a specific account field going back five years, would you be able to produce it?
How did this article make you feel?
Comments
Salesforce Tip