Audit, Compliance & Observability

Field History Tracking is evidence—not an audit strategy

JSBC Labs28 September 20268 min read

Start with the question the evidence must answer

Teams often enable Field History Tracking and declare the audit requirement complete. The related list looks convincing: a field changed, an old value became a new value, a user and timestamp appear beside it. That is useful evidence. It is not proof that the organisation can reconstruct a regulated decision, investigate misuse or demonstrate control over the system.

Audit design should begin with explicit questions. Who changed a customer’s risk status? Which values changed? Who viewed or exported sensitive data? Which permission or automation allowed the action? What business approval justified it? Can the evidence still be produced after the required retention period? No single Salesforce feature answers all of those questions, so the control must be designed as a set of complementary evidence sources.

Field history records selected state changes

Field History Tracking records changes to fields selected for an object. It is valuable for high-risk attributes such as bank details, consent, pricing, ownership, status and approval outcomes. The history supports troubleshooting, customer queries and forensic review because it connects old and new values to a time and an acting identity.

Its boundary matters. It does not retrospectively reconstruct changes made before tracking was enabled. It does not explain why a value changed, whether the actor was authorised, who merely viewed the record, whether data was exported, or which configuration change altered behaviour. It also cannot prove that an untracked field remained unchanged. Treat the selected-field list as a governed evidence scope, not a one-time setup checkbox.

Select fields from risk, not convenience

Tracking every field available can create noise without improving control. Tracking only fields that happen to appear on a page layout can miss calculated, integration-managed and security-relevant attributes. Build the list from business risk: financial impact, legal obligation, identity, consent, entitlement, ownership, lifecycle and fields that determine downstream automation.

For each tracked field, document the threat or control objective, evidence owner and review use case. Include hidden and API-managed fields when they affect decisions. Revisit the list when releases add fields or processes. Standard Field History Tracking has product limits on how many fields can be selected, while Field Audit Trail expands that capacity. Limits should force prioritisation or a licensing decision—not silent gaps.

Retention must match the obligation

Salesforce’s current documentation says that without Field Audit Trail, field history is retained for up to 18 months in the org and up to 24 months through the API. Those windows may be shorter than contractual, tax, employment, financial-services or privacy obligations. An auditor asking for evidence from three years ago will not accept that the related list once displayed it.

Define retention from policy and jurisdiction, then choose the mechanism. That may mean Field Audit Trail, a controlled external archive or both. Salesforce states that Field Audit Trail can retain archived field history until it is manually deleted. Retention is only defensible when export, archive, legal hold, deletion and restore procedures are tested. ‘We bought Shield’ is not evidence that the required history is retrievable.

Configuration changes need different evidence

A business field may change because an administrator edited a permission set, validation rule, Flow, integration or sharing configuration. Record history shows the resulting data change; it does not explain the system change that made it possible. Setup Audit Trail covers administrative and configuration activity and records who changed what and when.

Salesforce allows the complete setup history for the previous 180 days to be downloaded, after which setup audit records are deleted. If the organisation needs longer evidence, automate or schedule protected exports before that window closes. Link releases and emergency changes to tickets, approvers and deployment records. A configuration log becomes useful audit evidence when it can be reconciled with an authorised change process.

User activity is not field history

Many investigations begin with behaviour rather than a changed value: a report was exported, an API client downloaded records, a user logged in from an unusual location or a privileged function was invoked. Event Monitoring provides detailed security, usage and performance events for supported activity. It complements field history; it does not replace it.

Salesforce exposes event log files through the EventLogFile object and supports integration with external storage and analytics. The official API guide also warns that event logs are not a durable system of record and that delivery can contain gaps or duplicates in some circumstances. Consumers therefore need idempotent ingestion, completeness checks and an agreed response when expected files do not arrive.

Capture business context deliberately

Old value, new value, user and timestamp rarely explain a decision. A credit limit can legitimately change after approval or illegitimately change without one; the field history looks similar. A service account may update consent because a verified customer request arrived, or because an integration replayed stale data. The audit question is about authority and intent, not only mutation.

For high-risk operations, capture a case, request, approval, source system, correlation identifier or reason code alongside the change. Prefer structured references over free text. Propagate the identifier through Flow, Apex, middleware and downstream systems so the evidence can be joined. Do not put credentials, personal data or entire payloads into diagnostic fields simply because investigators might need context later.

Protect the evidence and the people who can reach it

Audit data can itself contain sensitive information, including previous values that users are no longer allowed to see. Limit access to history, event logs, exports and archives according to job responsibility. Separate people who administer controls from those who review evidence where the risk justifies it. Monitor changes to the permissions that expose or delete audit data.

External storage should preserve integrity, encryption, access logging, retention and defensible deletion. Immutability is useful only when privacy and legal-hold obligations are also understood. Define who can request evidence, who approves the request and how delivery is recorded. An uncontrolled CSV on an administrator’s laptop is not a stronger audit trail merely because it survived longer than Salesforce.

Design an evidence matrix

Create a matrix that maps each audit question to its source, coverage, latency, retention, owner and retrieval procedure. Field History Tracking or Field Audit Trail covers selected record changes. Setup Audit Trail covers supported configuration changes. Event Monitoring covers supported user and system activity. Deployment records, approval objects, integration logs and external security platforms supply context the native sources do not contain.

Record the known gaps. Some changes may originate from automated or shared technical contexts; some events are available only with particular editions or subscriptions; some evidence arrives after the activity. Decide whether each gap is accepted, mitigated with another control or requires architecture change. A documented limitation is governable. An assumed capability usually appears only when an investigation fails.

Test retrieval, not only capture

A control is ineffective if evidence exists but nobody can produce it. Run a periodic exercise around a representative high-risk change. Ask the control owner to identify the field mutation, related approval, configuration state, acting identity and relevant activity. Verify timestamps, time zones, correlation and retention. Measure how long the answer takes and whether privileged manual access was required.

The JSBC Labs view is that Field History Tracking is a precise evidence source inside a wider audit architecture. Use it for the changes it records well, then add retention, setup evidence, behavioural monitoring and business context according to risk. Govern the scopes, protect the outputs and rehearse investigation. An audit strategy is complete when a material question can be answered reliably years later—not when a history related list is visible today.