Salesforce Field History Tracking: Setup, Limits, and Audit Best Practices

Salesforce field history tracking records selected field changes on supported standard objects and custom objects, including who made the change, when it happened, and the old and new values where Salesforce stores them. You enable it per object in "Setup", though a few hard limits on native tracking exist: 20 fields per object, 18 months of history in the UI, and 24 months through the API.

That makes field history tracking useful for admin troubleshooting, RevOps controls, and audit review. It also means you need to be precise about which fields you track. And once integrations or AI agents update Salesforce, the audit gets even harder. Salesforce can show the user tied to the update, but field history alone can't explain the full cross-system workflow that caused the change.

In this guide, we will walk you through the process of properly configuring field history tracking, working within its limits, and querying the changes it records, and we also map out where native history is enough and where a cross-system workflow needs a broader audit trail.

Key Takeaways

• Salesforce field history tracking records changes to selected fields on supported standard objects and custom objects, including the user, timestamp, old value, and new value where supported.
• Native field history tracking is limited to 20 fields per object, with 18 months available in the UI and 24 months available through the API.
• Setup requires enabling tracking on the object, selecting fields, and adding the history-related list to the relevant page layout.
• Field history can show that either an "API User" or an "Integration User" made a change, but it doesn't trace why that external process acted or what happened next in an ERP.
• Engini provides one managed execution layer for AI agents working across Salesforce and systems of record, with scoped permissions, guardrails, and an audit trail built into the platform.

Defining Field History Tracking in Salesforce

Field history tracking in Salesforce is a native audit feature that records record-level changes for selected fields. It applies to supported standard objects and custom objects, and it creates a history record when a tracked field changes.

A field history record can include:

• The field that changed.
• The user associated with the change.
• The date and time of the change.
• The old value, where Salesforce stores it.
• The new value, where Salesforce stores it.

This gives you a basic change log for fields such as "Opportunity Amount", "Stage", "Close Date", "Account Owner", or a custom approval field.

Another thing to note is that Salesforce stores history in object-specific history tables. For custom objects, that history object uses the "__History" suffix, and the Salesforce Object Reference shows, for example, that a custom object named "Invoice__c" has a related history object named "Invoice__History".

For standard objects, Salesforce uses object-specific history objects where supported, such as "AccountHistory", "OpportunityFieldHistory", or "CaseHistory". Keep in mind that the exact object name is key when you query history through SOQL.

Field history tracking isn't the same as a full event log, though. This is because it doesn't record every screen view, automation decision, or downstream system action but instead field changes that match the tracking configuration.

Note: "CreatedBy" and "CreatedDate" both show who created a record and when, but field history is meant to track changes to selected fields. If you need a complete creation payload, you shouldn't expect the field history table to act as a full record snapshot.

Adapting to the Hard Limits of Native History Tracking

Native history tracking fields Salesforce supports are no doubt useful, but the limits can be troublesome. If you want the specifics, Salesforce states that you can track up to 20 fields per object, and that field history data is retained for up to 18 months through the UI and up to 24 months through the API in standard field history tracking.

The table below lays out the limits you should plan around.

Choosing Which 20 Fields to Track

The 20-field limit creates a real administrative tradeoff. On an "Opportunity", you may want to track "Stage", "Amount", "Close Date", "Forecast Category", "Owner", "Primary Campaign Source", approval fields, custom scoring fields, and integration status fields. In fact, you can likely hit that limit before compliance, finance, and RevOps can even agree on the list.

The strategy here is to rank fields by audit value instead. Here, we recommend tracking fields that affect revenue recognition, customer commitments, ownership, approvals, forecasts, and downstream ERP actions because those changes carry audit value. Conversely, avoid spending the 20 fields on low-risk text notes since they can consume tracking capacity without adding useful evidence.

Salesforce Field Types That Need Extra Care

Formula fields are a common trap here. A formula value changes because its inputs or referenced records change, so treating the formula itself as the audit source can mislead reviewers. To avoid this, track the underlying fields that drive the formula when you need an explainable history.

Long text area fields also need attention. Salesforce documents that for certain field types, including long text area fields, history may show that the field changed without preserving the full old value and new value. That may be acceptable for admin troubleshooting, but it may not satisfy an audit request that needs exact before-and-after values.

Multi-select picklists deserve the same caution in your own organization as they can be difficult to report on cleanly because values are stored as a set rather than a single scalar business state. So, if a multi-select picklist drives a controlled process, test the resulting history before relying on it for audit evidence.

Note: Native tracking is also scoped to Salesforce. However, it records the Salesforce field change instead of the full business process.

Enabling Field History Tracking

You enable field history tracking from "Setup" → "Object Manager". The exact labels can vary slightly by object and Salesforce setup, but the administrative path is typically consistent.

Note: Decide which 20 fields are most important before you enable tracking, and treat the choice as a governance decision rather than a cleanup task.

Configuration Steps

For most standard and custom objects, the setup path is the same:

1. Go to "Setup" → "Object Manager".
2. Select the standard object or custom object you want to track.
3. Go to "Fields & Relationships" → "Set History Tracking".
4. Enable history tracking for the object, if it isn't already.
5. Select up to 20 fields and save your changes.

For custom objects, Salesforce's custom object field history documentation covers the extra checks: confirm the object supports field history tracking and that tracking is enabled in the object definition.

After you save, Salesforce starts tracking changes going forward, but it won’t backfill changes from before tracking was enabled. During audit remediation this can become a real bottleneck, because enabling tracking today doesn't prove what happened last quarter.

Adding the History-related List

Enabling tracking creates the history data, but users also need a way to see it, so make sure to add the history-related list to the page layout for the object:

1. Go to "Setup" → "Object Manager".
2. Select the object → "Page Layouts".
3. Choose the relevant layout, then add the object's history-related list and save the layout.

The related list then lets admins and authorized users see tracked changes from the record page. If users can't see the related list, check both the layout assignment and their object or field access. With that said, field-level security still matters here because Salesforce permissions shape what users can access.

Tip: For Lightning record pages, also confirm that the layout and related list components expose the related list as expected. A missing related list often looks like a tracking problem, but the data may exist while the page layout hides it.

Querying and Reporting on Tracked Fields

Salesforce tracking field history can be reviewed from record pages, reports, and SOQL. The right method depends on whether you’re answering an admin question, a business reporting question, or an audit question.

For day-to-day review, the history-related list is usually enough. It shows tracked changes on the record page, which helps when a sales manager asks why an "Opportunity Amount" changed.

For reporting on field history, Salesforce supports history report types for certain objects and configurations. The report output is useful when you need to review patterns, such as frequent stage changes, owner changes, or approval field updates.

For technical investigation, SOQL gives you more control. History object architecture is crucial here because each object has its own history storage pattern.

For custom objects, make sure to query the "__History" object. A basic query structure looks like this:

SELECT ParentId, Field, OldValue, NewValue, CreatedById, CreatedDate

FROM Invoice__History

WHERE ParentId = 'a00XXXXXXXXXXXX'

ORDER BY CreatedDate DESC

For supported standard objects, use the relevant history object. For example, "Opportunity" field changes can be queried from "OpportunityFieldHistory". All in all, a few fields carry most of the audit value, as the table below shows.

A typical investigation usually starts with the field and timestamp, then moves to the user. If "CreatedById" maps to an integration user, the Salesforce record tells you which credential made the update. It doesn't, however, explain the external decision path that caused that credential to act.

A field history row can also show that an API user changed "Opportunity Amount" at 10:14 a.m. It can't show that the update came from an AI agent decision though, nor from a middleware rule, an ERP sync, or a failed retry unless you have external logs that connect those events.

"Field Audit Trail" vs. "Field History Tracking"

"Field History Tracking" and "Field Audit Trail" solve related problems, but they aren't the same thing. Native field history tracking gives you standard change history with the 20-field limit and standard retention. "Field Audit Trail", on the other hand, is part of Salesforce Shield and is designed for longer retention and audit policy control.

The table below lays out the differences between both.

"Setup Audit Trail" is another separate Salesforce feature. It tracks setup and configuration changes, such as admin changes to metadata or organizational settings, but not business field changes on records.

For SOX programs, "Field History Tracking" may support evidence for record-level changes. "Field Audit Trail" may support longer retention, though. Finally, "Setup Audit Trail" supports evidence about configuration changes.

Note: None of these, by itself, proves the full path of a cross-system transaction. If an automated process updates Salesforce and then writes to an ERP, you will need evidence from more than one system.

Tracking AI Agent and Integration Changes

When an integration or AI agent updates Salesforce through an authenticated user, field history records the user tied to that update. In real enterprise setups, that user is often a shared API user or integration user.

That can be a valid Salesforce setup. Dedicated integration users help you manage permissions, API access, and ownership boundaries. Yet Salesforce still enforces its own object permissions, field-level security, validation rules, and transaction constraints.

The audit issues start when the history row is the only evidence you have, so something like:

• Field: Amount.
• Old value: previous amount.
• New value: revised amount.
• User: Integration User.
• Timestamp: date and time of change.

What the History Row Can't Show

That row can confirm that Salesforce recorded a change. It doesn't, however, explain why the integration changed the field, which external system triggered it, which agent or workflow made the decision, or whether the downstream write completed or not.

This is especially hard in cross-system workflows. An AI agent may update a Salesforce "Opportunity", then create a sales order in Oracle NetSuite. Salesforce field history can then show the "Opportunity" update, but it can't trace the NetSuite sales order creation from the same audit view.

The same issue appears in event-driven transactions. A Salesforce change event can signal that a record changed. That event isn't the same as a validated write in the destination system, though. The path to a completed ERP transaction may instead require enrichment, matching, scoped permissions, idempotency and duplicate checks, proper error handling, and an auditable outcome.

Cross-system evidence also needs observability around retries, mappings, and destination outcomes. If schema drift changes a mapped field, or a retry runs without idempotency checks, a Salesforce field history row may show only the local update. It won't prove that the full transaction was completed once, in the right system, with the right destination record.

Failed writes make this gap even more visible. For example, Salesforce may show that a status field changed to "Ready for ERP," but the ERP write may fail because of a missing customer match, validation rule, closed accounting period, or duplicate order check. In other words, native field history doesn't give you a replayable cross-system record of that failed write.

For SOX and internal audit, field history has a defined scope, too. It records selected Salesforce field changes rather than the full business process across CRM, ERP, and the agent or integration that coordinated the work.

Why Cross-System Governance Matters Today

Native Salesforce controls are still the right starting point. "Field History Tracking", "Field Audit Trail", "Setup Audit Trail", field-level security, and object permissions all have clear roles inside Salesforce.

The next decision is whether the workflow stops inside Salesforce. If it does, native controls and targeted automation may be enough. If an AI agent or integration acts across Salesforce and an ERP instead, you need an execution record that follows the action across multiple systems.

How Engini Can Help

Engini is the execution layer between AI agents and systems of record. It gives agents a governed route to act across Salesforce and ERP workflows through our Agent Gateway tool, with the Agent Policy tool controlling permissions, guardrails, and auditability.

That can come in handy when an agent acts across CRM and ERP. With Engini, you get one managed, governed layer for the actions routed through it, with scoped permissions, guardrails, and a full audit trail built into the platform. A failed write can now be surfaced to the user, reviewed in the audit trail, and replayed where supported and safe after the cause is corrected.

Putting Salesforce Field History Tracking to Work

Field history tracking is the right tool for recording selected field changes inside Salesforce, provided you plan around the 20-field limit and the UI and API retention windows, and reach for "Field Audit Trail" when you need longer retention.

The harder part is the scope: a history row proves what changed on a tracked field, but not the cross-system path that produced it. So, make sure to map that boundary before you rely on native history for an audit, and line up a second evidence source wherever an agent or integration needs to carry the work beyond Salesforce.

Frequently Asked Questions

How long does Salesforce track field history?

Salesforce Help documents that standard field history stays available for up to 18 months in the UI and 24 months through the API. The timing catch is that enabling tracking only after an audit concern surfaces won't rebuild earlier history, so you'll need another evidence source for that older period.

How many fields can you track history on in Salesforce?

Salesforce native field history tracking supports up to 20 tracked fields per object. The harder question is which evidence belongs outside field history: if a field drives an ERP write, an approval, or a SOX control, keep its history row connected to the process log that explains why the change happened.

Can I track the field history of a custom object in Salesforce?

Yes, for custom objects that support history tracking. If the expected history is missing, check that history tracking is enabled on the object, the field is selected for tracking, and the history-related list is visible to the reviewer. For SOQL investigations, custom object history uses the "__History" suffix.