Field History Tracking and Field Audit Trail

Why This Topic Matters
Every organization eventually needs to answer the question: who changed this value, when, and what was it before? Whether it is an Opportunity Amount that was quietly reduced before close, a Case Status that was flipped without explanation, or a regulated industry that must prove data lineage for seven years, Salesforce provides two closely related tools for this: Field History Tracking (included with the platform) and Field Audit Trail (a paid Salesforce Shield add-on). On the Advanced Administrator exam this topic sits inside the Auditing and Monitoring section, and questions almost always test whether you can (1) tell these two features apart from each other and from Setup Audit Trail and Login History, (2) recall their limits and retention periods, and (3) recognise what can and cannot be tracked.

Part 1: Field History Tracking (Standard Feature)

What it is
Field History Tracking records changes to selected fields on a record. For each change it stores the field name, old value, new value, the user who made the change, and the date/time. The data is displayed in a History related list (for example, Account History or Case History) and can be reported on with dedicated history report types.

Where it is enabled
Setup → Object Manager → select the object → Fields & Relationships → Set History Tracking. For standard objects you must first tick the Enable [Object] History checkbox, then select the fields. For custom objects, you first check Track Field History on the object definition, then choose fields. After enabling, you must add the History related list to the page layout or users will not see anything.

Key limits and behaviours
• You can track up to 20 fields per object.
• Supported standard objects include Accounts, Contacts, Leads, Opportunities, Cases, Contracts, Entitlements, Service Contracts, Contract Line Items, Solutions, Products, Price Books, Orders, Order Products, Assets, Campaigns, Individuals, Knowledge Articles, and all custom objects. (Person Accounts are supported through the Account and Contact history settings.)
• Tracking is not retroactive. Changes made before you enabled tracking on a field are never captured.
• Changes made through any channel – UI, API, Data Loader, Apex, Flow, workflow field updates – are tracked.
• Field history data does not count against data storage.
• Fields that cannot be tracked: formula fields, roll-up summary fields, auto-number fields, Created By, Last Modified By, and certain system fields.
• Fields tracked without old/new values: Long Text Area, Rich Text Area, Multi-Select Picklists, and any field whose values exceed 255 characters show only that the field was changed/edited, not what it changed from or to.
• For Opportunities, the history object is OpportunityFieldHistory. This is distinct from OpportunityHistory (Stage History), which automatically tracks Stage, Amount, Probability, and Close Date whenever Stage changes – that one is always on and does not use one of your 20 fields.
• For custom objects the history object is named MyObject__History.
• Lead conversion: history on the Lead does not carry over to the converted Account/Contact/Opportunity records.

Retention
Salesforce retains standard field history data for up to 18 months through the user interface (related lists and reports) and up to 24 months via the API. Without Field Audit Trail, Salesforce reserves the right to delete field history data older than 24 months. If a question says users need to see data from three years ago in the History related list without any add-on, the answer is that standard Field History Tracking cannot guarantee that.

Reporting
When tracking is enabled, Salesforce creates report types such as Account History, Opportunity Field History, Case History, and [Custom Object] History. Admins can build reports showing Old Value, New Value, Edited By, and Edit Date, and can filter by field. These are standard report types, so they are available automatically – you do not need to build a custom report type.

Deleting field history
Admins with the Delete From Field History permission (and Delete From Field History Archive for archived data) can delete field history records via the API. This is sometimes needed for data-privacy (right to be forgotten) requests.

Part 2: Field Audit Trail (Salesforce Shield Add-On)

What it is
Field Audit Trail extends Field History Tracking for compliance-driven organizations (finance, healthcare, government). It lets you define a retention policy that keeps field history data for up to 10 years and raises the tracking limit to 60 fields per object. It is a paid feature, sold as part of Salesforce Shield (alongside Platform Encryption and Event Monitoring) or as a standalone add-on.

How it works
1. You still enable Field History Tracking on the object and fields exactly as before – Field Audit Trail builds on top of it.
2. You define a HistoryRetentionPolicy for each object using the Metadata API (Workbench, Salesforce CLI, Ant Migration Tool, or a Metadata API tool). There is no point-and-click UI in Setup for creating the policy – this is a favourite exam detail.
3. The policy has two parts:
  • ArchiveAfterMonths – how long (1 to 18 months) data stays in standard field history (visible in the History related list) before it is moved to the archive.
  • ArchiveRetentionYears – how long (up to 10 years) the data is retained in the archive before being eligible for deletion.
4. Archived data is stored in the FieldHistoryArchive big object. Big object storage is separate from standard data storage.
5. Archived data is not shown in the History related list or standard reports. It is retrieved with SOQL (with required filter ordering on FieldHistoryType, ParentId, and CreatedDate) or Async SOQL, typically by exporting to an external compliance system or surfacing it through custom development.

Key points
• 60 tracked fields per object (versus 20 standard).
• Retention up to 10 years (versus 18/24 months standard).
• Policies are deployed via Metadata API, not Setup.
• Archived data lives in the FieldHistoryArchive big object.
• Supports the same major objects as Field History Tracking (Accounts, Contacts, Leads, Opportunities, Cases, Assets, Entitlements, Service Contracts, Contract Line Items, Solutions, Products, Price Books, custom objects, and others).
• Users need the View All Data-type access or appropriate permissions to query the archive; deletion requires Delete From Field History Archive.

Part 3: Don't Confuse It With Other Auditing Tools

Exam questions deliberately blur these. Memorise the differences:

Field History Tracking – changes to record data; up to 20 fields; 18 months UI / 24 months API; visible in History related list and history reports.
Field Audit Trail – same record-data changes, but up to 60 fields and up to 10 years; Shield add-on; policy via Metadata API; archive in big object.
Setup Audit Trail – changes to configuration/metadata (profiles, fields created, permission changes, login-as activity); last 20 entries shown in Setup, 180 days downloadable as CSV; no setup is required.
Login History – who logged in, when, from where, success/failure; 6 months; downloadable.
Event Monitoring – Shield add-on; event log files for user activity (reports run, exports, API calls, page views).
Record Modified Fields – Last Modified By/Date only tell you who touched the record most recently, not what changed.

Part 4: Exam Tips – Answering Questions on Field History Tracking and Field Audit Trail

Tip 1: Spot the keyword triggers.
• Compliance, regulatory, audit requirement, 7 years, 10 years, long-term retention, more than 20 fields → Field Audit Trail.
• Who changed this field value, previous value, see the history of changes on a record → Field History Tracking.
• Who created/changed a field, profile, permission set, validation rule, or logged in as another user → Setup Audit Trail.
• Who logged in, failed logins, IP address → Login History.

Tip 2: Know the numbers cold. 20 fields (standard), 60 fields (Field Audit Trail), 18 months (UI), 24 months (API), 10 years (archive), 1–18 months (ArchiveAfterMonths), 180 days (Setup Audit Trail). If an answer option uses a number outside these, it is almost certainly a distractor.

Tip 3: Remember what cannot be tracked. If the scenario asks to track a formula field or roll-up summary, the correct response is that it is not possible – consider tracking the underlying source fields instead, or create a workflow/flow to copy the value into a trackable field. If the scenario involves a Long Text Area or Multi-Select Picklist and users complain they cannot see old and new values, the answer is that is expected behaviour; only the fact that the field was edited is recorded.

Tip 4: Watch for the related-list trap. A common scenario: the admin enabled history tracking but users cannot see any history on the record. The fix is to add the History related list to the page layout. Another variant: users want to see changes from before tracking was enabled – not possible, tracking is not retroactive.

Tip 5: Opportunity Stage History is separate. If a question asks about tracking stage progression, duration in stage, or Amount/Probability/Close Date at each stage change, think Stage History (OpportunityHistory) and the Opportunity History report type, not Field History Tracking.

Tip 6: Field Audit Trail is configured through the Metadata API. If an option says to set the retention policy in Setup via a checkbox or a picklist, it is wrong. The correct answer references deploying a HistoryRetentionPolicy with the Metadata API (Workbench, SFDX/CLI, or Ant).

Tip 7: Archived data is not in the related list. If a question states Field Audit Trail is active and users ask why data older than the ArchiveAfterMonths setting disappeared from the History related list, explain that it has moved to the FieldHistoryArchive big object and must be queried with SOQL/Async SOQL.

Tip 8: Storage questions. Field history data does not count toward data storage, and archived Field Audit Trail data is stored in big-object storage. If an option claims enabling tracking on 20 fields will consume your data storage, treat it as a distractor.

Tip 9: Reporting answers. When the requirement is to report on who changed a field over the last quarter, the answer is a standard [Object] History report type – not a custom report type, not a dashboard on Last Modified Date, and not Event Monitoring.

Tip 10: Eliminate by scope. Ask yourself: is the change to data or to configuration? Is the need short-term visibility (≤18–24 months) or long-term compliance? Is the solution declarative in Setup or API-only? Answering these three questions narrows almost every scenario to a single correct option.

Quick Recap
Field History Tracking: free, 20 fields/object, old/new values, History related list, history report types, 18 months UI / 24 months API, not retroactive, cannot track formula/roll-up/auto-number, long text and multi-select show only edited. Field Audit Trail: Shield add-on, 60 fields/object, HistoryRetentionPolicy via Metadata API with ArchiveAfterMonths (1–18) and ArchiveRetentionYears (up to 10), archived into the FieldHistoryArchive big object, queried via SOQL/Async SOQL. Keep these clearly separated from Setup Audit Trail, Login History, and Event Monitoring, and you will handle every question in this area with confidence.