Auditability, Compliance & Data Governance

Field History Tracking is not an audit architecture

JSBC Labs2 November 20268 min read

Capturing changes is not the same as proving control

A compliance review asks who changed a customer's risk rating, what the previous value was, whether the change was authorised and which process approved it. The team opens the record's History related list and finds a username, timestamp and two values. That is useful evidence, but it does not establish why the change occurred, whether the actor was entitled to make it, whether the evidence is complete or how long it will remain available.

The JSBC Labs position is that Field History Tracking is a capture mechanism inside an audit architecture. Salesforce records tracked field changes in an object's related history object, but the organisation must still define obligations, evidence coverage, retention, access, review and response. Enabling a few checkboxes without that design creates a visible trail that can be mistaken for a defensible control.

Start with audit questions, not a field list

Write the questions an auditor, investigator or operational owner must answer. Which decisions need before-and-after values? Which events require the actor, time and business justification? Must evidence survive deletion of the source record? How quickly must it be retrieved, and for how many years? Map each obligation to a regulation, policy or business risk and name the person accountable for reviewing exceptions.

Only then choose fields. Prioritise values that change authority, money, eligibility, consent, contractual status or security posture. Tracking every convenient field produces noise and can make meaningful events harder to find; tracking only the final status can hide the decision path. Standard Field History Tracking supports a bounded set of fields per object, so use that constraint to force an explicit evidence model rather than a first-come configuration.

Know what the history record cannot prove

History begins when tracking is enabled; Salesforce does not backfill earlier changes. For long text fields over 255 characters, the platform records that a change occurred but not the actual old and new text. Timestamps are precise to one second, and Salesforce notes that changes to the same tracked field in the same second can share a timestamp without guaranteed commit ordering. These are material boundaries for investigations that expect a complete narrative.

A user value also needs context. An integration user may represent several upstream actors, and Automated Process can represent multiple automations. The field history row identifies the Salesforce actor, not automatically the originating person, approval, API request or business reason. Where that context matters, preserve a correlation ID, source-system identity, reason code or approval reference as part of the transaction and link it to operational evidence.

Retention is a policy decision

Without Field Audit Trail, Salesforce documents field history availability for up to 18 months in the user interface and up to 24 months through the API. Older history can be queried with supported export methods during the API window, but this is not a long-term records strategy. If the business obligation is seven years, a related list that becomes sparse after eighteen months is an architectural mismatch.

Field Audit Trail extends retention and archives history in the FieldHistoryArchive big object according to a retention policy. Archived evidence is API-accessed rather than simply browsed like the live related list, and queries use a constrained subset of SOQL. Design the retrieval path before promising indefinite evidence: specify who can run it, how results are exported, how a record is reconstructed and how legal deletion requirements are applied.

Use the correct evidence plane

Field history answers selected data-change questions. Setup Audit Trail records administrative configuration changes and provides downloadable setup history for the past 180 days. Event Monitoring provides security, usage and performance evidence such as data access, logins and API activity. Approval history, login history, integration logs and external identity-provider records answer still different questions. No single Salesforce feature is a universal ledger.

Build an evidence map showing each control question, source, native retention, export path, owner and review frequency. A permission-set change belongs in Setup Audit Trail; a report export may belong in Event Monitoring; a change to a regulated field belongs in field history; the business justification may belong in an approval or case. Correlate these sources instead of forcing one tool to explain events it was never designed to capture.

Protect the evidence and its meaning

Audit evidence can expose sensitive previous values, actors and operational patterns. Restrict access to history objects, archive queries, exports and monitoring tools according to classification and investigative need. Separate the ability to administer tracking from the ability to approve policy exceptions. Route exports to controlled storage with defined access, integrity checks, retention and deletion rather than unmanaged spreadsheets sent between reviewers.

Govern semantic change too. Renaming a status, repurposing a field or changing an integration's identity can make old rows technically intact but operationally misleading. Maintain a dated data dictionary for audited fields, principal mappings and reason codes. When a field is replaced, define how evidence before and after the change will be interpreted. Auditability depends on stable meaning as much as preserved rows.

Make audit configuration releasable

Treat tracking and retention policies as governed configuration. Add audited-field requirements to solution design, include applicable metadata in source control, and validate in the delivery pipeline that a deployment has not disabled tracking or removed a required field. Salesforce Well-Architected guidance recommends automated compliance checks that detect weakened permissions, disabled audit settings and other non-compliant configuration changes.

Release testing should create a representative change through each important channel—user interface, Flow, Apex and integration—and verify the expected actor, values, timestamp and correlation data. Test retrieval from the live history object and, where licensed, the archive path. Also test deletion and masking obligations. A control that has never been exercised is a configuration assumption, not reliable evidence.

An audit trail needs an operating rhythm

Evidence that nobody reviews is storage, not control. Define daily or weekly exception checks for high-risk changes, periodic access reviews for investigators and scheduled exports before native retention expires. Set thresholds for unexpected value changes, privileged actors, bulk activity and changes outside approved windows. Assign the response: investigate, correct data, revoke access, preserve evidence or escalate to compliance.

Review the architecture whenever fields, integrations, regulations or business processes change. Sample complete cases from decision to evidence and prove that a reviewer can reconstruct the event without privileged tribal knowledge. Field History Tracking remains valuable—but only when it sits inside a designed system of policies, complementary evidence, controlled retention and accountable review. That is the difference between a history list and an audit architecture.