Salesforce Field Audit Trail is a paid Salesforce add-on that extends field history tracking so you can keep a detailed record of field changes far longer than the platform allows by default. It raises the tracking limit to up to 200 fields per object, archives history into a dedicated big object called FieldHistoryArchive, and lets you define how long that history is kept, including keeping it indefinitely.
That matters because standard field history tracking was not built for regulated environments. It covers up to 20 fields per object and retains data for roughly 18 months, which leaves gaps that auditors notice quickly when SOX, GDPR, or HIPAA obligations require a longer evidentiary trail.
This guide explains what Field Audit Trail does, how it differs from the other Salesforce audit features it gets confused with, what it costs, how to enable and configure it, where its limits sit, and where you still need backup and recovery tooling alongside it.
What Is Salesforce Field Audit Trail and When Do You Need It?
Field Audit Trail is a component of Salesforce Shield, the add-on suite that also includes Platform Encryption and Event Monitoring. It builds on field history tracking rather than replacing it: you still enable tracking per object and per field, and changes still land in the object's history related list. What Field Audit Trail adds is scale and permanence. More trackable fields, a configurable archive, and retention that outlasts the standard window.
One distinction is worth settling early, because these three features get used interchangeably and they do different jobs.
Field Audit Trail vs. Field History Tracking vs. Setup Audit Trail
Field History Tracking and Field Audit Trail both record changes to data inside records. Setup Audit Trail records administrative changes to the org's configuration. If you need to know who edited a customer's contract value, that is field history. If you need to know who changed a permission set, that is Setup Audit Trail.
A practical consequence: Field Audit Trail does nothing for Setup Audit Trail's 180-day limit. Organizations that need multi-year proof of configuration change control have to export or archive that data separately, which is a common gap in audit preparation.
Key Features of Salesforce Field Audit Trail
Three capabilities account for most of the value.
1. Track Up to 200 Fields Per Object
Field Audit Trail raises the field history tracking limit from 20 fields per object to up to 200. That is the difference between choosing which regulated fields you can afford to monitor and simply monitoring all of them.
Even with 200 available, it pays to be deliberate. Rank fields by compliance impact and change frequency rather than enabling everything reflexively, since every tracked field adds history rows that someone eventually has to query. A simple three-tier split works well: high priority for regulatory-sensitive data such as financial amounts, personal data, and approval status; medium for business-critical changes; low for informational updates.
Platform limits do change between releases, so confirm the current figure in Salesforce documentation before you design around a specific number.
2. Configure Archiving, Retention, and Deletion
This is the feature most often described incorrectly. Field Audit Trail does not impose a ten-year ceiling. It lets you keep field history indefinitely, and what you configure is the timing of two separate phases.
- The active phase. History stays in the object's own history list, where it appears in the record's history related list and is queryable through standard SOQL. By default Salesforce archives this data after 18 months in production and after one month in sandboxes.
- The archive phase. Salesforce copies history into the FieldHistoryArchive big object. The first copy can take a long time because it writes all existing history covered by your policy; subsequent copies are incremental. By default, archived data is stored until you delete it.
You control both phases with a retention policy defined per object, setting how many months history stays active before archiving and how many years it is retained in the archive. Setup instructions are below.
One point worth stating plainly, because it is frequently reported the other way around: field history tracking data and Field Audit Trail data do not count against your org's data storage limits. You do not need to buy storage to accommodate a longer retention policy. What longer retention does affect is query volume and the time archive jobs take, not your storage allocation.
3. Access Audit Data Through the UI and APIs
Recent history is visible in the record's history related list and can be surfaced in reports, which covers most day-to-day questions. Beyond that, three access paths matter:
- History objects such as AccountHistory or ContactHistory hold recent, pre-archive changes and are queryable with standard SOQL.
- The FieldHistoryArchive big object holds archived history. Queries against it have specific rules, covered in the setup section below.
- REST, SOAP, and Tooling APIs provide programmatic access for compliance reporting, SIEM integration, and forensic analysis, which is what makes audit history usable at scale rather than one record at a time.
Salesforce Field Audit Trail Limits
Knowing where the boundaries sit prevents unpleasant surprises during an audit.
The limitation teams underestimate most is scope. Field Audit Trail covers field-level data changes and nothing else. It does not capture metadata deployments, permission changes, or configuration history, and it will not restore anything. Building complete audit trails across a regulated Salesforce environment means combining it with Setup Audit Trail, Event Monitoring, deployment history, and backup.
How Much Does Salesforce Field Audit Trail Cost?
Field Audit Trail is not included in standard Salesforce licensing. It is a paid add-on, available as part of Salesforce Shield or, in some cases, licensed separately.
Salesforce prices Shield as a percentage of your net Salesforce spend rather than as a flat per-user fee, which means the cost scales with the size of your existing contract instead of with how much history you track. Publicly circulated percentages vary and are not authoritative, so treat any figure you find online as an estimate and confirm current pricing with your Salesforce account executive.
Two things are worth clarifying when you do. First, whether Field Audit Trail can be licensed on its own or only as part of the full Shield bundle, since that materially changes the number. Second, whether your edition qualifies, because Shield components are available on Enterprise, Performance, Unlimited, and Developer editions rather than across the board.
When Do You Need Salesforce Field Audit Trail?
Standard tracking is adequate for a lot of orgs. Field Audit Trail earns its cost in four situations.
- Regulatory retention obligations. Data privacy and industry regulations frequently require change history well beyond 18 months. Financial services commonly work to seven-year retention, healthcare often longer. Teams building toward SOX compliance in particular need field-level change evidence that outlives the standard window.
- Audit coverage across many fields. Organizations with complex approval workflows, frequent data migrations, or multiple integration touchpoints run past 20 tracked fields quickly. The higher limit is what lets you cover financial fields for one framework and personal data fields for another without choosing between them.
- Forensic investigation. When a security incident or data quality problem surfaces, investigators need to reconstruct exactly what changed, when, and by whom, going back further than the UI retains. Programmatic access matters here, because clicking through record history is not viable under time pressure.
- Governance and troubleshooting at scale. Long-run history makes it possible to spot patterns: a field that changes far more often than expected, an integration quietly overwriting values, or an approval step being bypassed. Those are hard to see in an 18-month window.
How to Enable and Set Up Field Audit Trail in Salesforce
Setup has two halves. Enabling and choosing fields is done in Setup; retention policies are deployed through the Metadata API. Both are required, and a common failure is doing the first and skipping the second, which leaves data tracked but never archived under a deliberate policy.
Step 1: Confirm Your License and Permissions
Confirm your org has Field Audit Trail provisioned, either through Shield or as a separate add-on, on a supported edition. Then check permissions:
- Customize Application to configure field history tracking.
- RetainFieldHistory to set retention policies and access archived history. This is the permission most often missing, and its absence is the usual explanation when FieldHistoryArchive queries return nothing.
- Deployment access to the target org, since retention policies are deployed as metadata.
Retention policies are supported on a defined set of standard objects plus custom objects. Check current Salesforce documentation for the supported list before planning coverage, since it has expanded over time.
Step 2: Enable Field History Tracking on the Object
In Setup, open Object Manager, select the object, and open Fields & Relationships. Choose Set History Tracking, then enable tracking for the object. Field Audit Trail builds on this, so nothing archives if tracking is not on.
Step 3: Select the Fields to Track
On the same screen, select the fields to track, up to the current per-object limit. Prioritize fields carrying regulatory exposure: financial amounts, personal data, approval status, and anything an auditor is likely to ask about. Add the object's History related list to page layouts if you want users to see changes on the record itself.
Step 4: Define the Retention Policy
Retention is configured through the HistoryRetentionPolicy metadata, defined inside the object's own metadata file rather than as a standalone component. Three values do the work: archiveAfterMonths is how long history stays in the org before archiving, archiveRetentionYears is how long it is kept in the archive, and gracePeriodDays delays the first archival run.
The example above keeps Account history active for six months, then archives it and retains it for ten years. Adjust both numbers to your obligations rather than defaulting to the maximum.
Step 5: Deploy the Policy
Deploy with the Salesforce CLI or any Metadata API client. Deploying a new policy overwrites the existing one for that object, so validate in a sandbox first.
Note that Salesforce does not return the default retention policy when you retrieve an object's metadata. Only custom policies come back, so an empty result does not mean no policy is in effect.
Step 6: Verify Recent and Archived History
Verification has two parts, because recent and archived history live in different places and behave differently.
First, make a test change to a tracked field and confirm it appears in the record's History related list. Then query the object's history object directly:
Second, once data has moved into the archive, query FieldHistoryArchive. This is where teams get stuck: archive queries have a required filter order. You must filter on FieldHistoryType first, then ParentId, then CreatedDate, in that sequence.
Do not expect archived records immediately. Nothing appears in FieldHistoryArchive until your configured archive window has elapsed, which is why a query returning no rows on day one is usually correct behavior rather than a misconfiguration.
What Are the Benefits of Salesforce Field Audit Trail?
Field Audit Trail strengthens compliance programs, improves visibility, and supports long-term governance in three main ways.
Supporting Regulatory Requirements
Extended retention lets you produce field-level change evidence across the multi-year windows that SOX, GDPR, and HIPAA programs work to. The higher field limit means you can cover financial fields and personal data fields at the same time instead of trading one framework against another.
Worth being precise, though: no Salesforce feature makes an organization compliant. Field Audit Trail supplies evidence that supports a compliance program. Whether that program satisfies a given regulation depends on your policies, your controls, and how the rest of your audit picture is assembled.
Forensic Investigation Capabilities
Programmatic access lets you extract specific field changes across defined timeframes and reconstruct a sequence of modifications with timestamps and user attribution. When an auditor or investigator asks who changed what and when, that is the difference between a definitive answer and an estimate.
Proactive Data Governance
Long-run history turns governance from reactive cleanup into pattern detection. You can report on modification trends, spot policy violations through change analysis, and give stakeholders transparent data lineage. Consistent retention across multi-year periods is what makes those reports comparable over time.
Common Issues with Salesforce Field Audit Trail and How to Fix Them
Field Audit Trail is reliable once configured, but a few issues come up repeatedly.
Technical Limitations and Workarounds
Even 200 tracked fields can be constraining on heavily customized objects. Prioritize fields holding personally identifiable information, financial data, and approval status. Where an object genuinely exceeds the limit, a secondary approach is to use a record-triggered Flow to write key changes into a custom audit object. Treat that as a supplement, not a replacement, since a custom object does not inherit the archive behavior or the storage exemption.
API rate limits apply to bulk retrieval of audit data. When building custom audit reports or exports, paginate your queries and design around the limits rather than into them.
Performance and Policy Considerations
Enabling retention policies on objects with extensive existing history triggers a large initial archive job. Schedule those changes during lower-usage periods so the first copy does not compete with peak activity.
Configure retention to your actual obligations rather than the maximum available. Longer retention is not free in operational terms: larger archives mean slower queries and more data to sift through during an investigation. Match the policy to the requirement.
Troubleshooting Common Issues
- Missing audit data. Usually a policy problem. Confirm your historyRetentionPolicy metadata covers the intended objects, and check Setup Audit Trail for recent changes to retention settings.
- Nothing in FieldHistoryArchive. Most often the archive window has not elapsed yet, or the querying user lacks the RetainFieldHistory permission. Check both before assuming a configuration fault.
- Gaps in historical data. Enabling Field Audit Trail does not retroactively recover history that standard tracking already aged out. Document the switchover date as the official start of complete audit history and tell compliance teams, so the gap is not misread during an audit.
- Access and permission issues. Field history respects field-level security. Users need read access to the original fields as well as the history objects. For compliance teams, build a permission set granting access to FieldHistoryArchive along with RetainFieldHistory.
Strengthen Auditability and Recovery with Flosum
Field Audit Trail answers what changed and when. It does not answer how you get the data back, and that distinction matters more than it first appears.
An audit trail is not a backup. Field Audit Trail records that a field changed; it cannot restore a deleted record, reverse a bad integration write, or rebuild a corrupted object. Salesforce's own recovery options are limited: the recycle bin holds deleted records for a limited period with a capacity cap, and native recovery assistance is slow and offers no guarantee of completeness.
Flosum’s Backup and Archive closes that gap. Composite Backup captures new, changed, and deleted data and combines it with existing backup data, so you can restore an entire dataset or a single field as it existed at a chosen point in time, without disrupting production or overwriting newer valid data.
The two work together rather than overlapping. Field Audit Trail provides the long-term visibility that audits and investigations require. Backup provides the recovery path when something needs to be undone. Salesforce does not automatically back up your customizations, integrations, reports, files, or metadata, so a compliance posture built on audit history alone leaves the recovery half unanswered.
Reach out to us to see how Flosum complements your Field Audit Trail setup with backup, recovery, and deployment audit history.
