In every Salesforce org, change is constant. Multiple admins might be updating fields, permissions, automation, and security settings — often at the same time. When you don’t have visibility into who is changing what and when, it can be difficult to investigate security incidents, satisfy auditors, or explain why production behavior suddenly changed after a release.
Salesforce does have a few native tools that can help. Setup Audit Trail records changes made in Setup, giving you a timeline of administrative and configuration updates such as permission changes, validation rules, and sharing settings. Field History Tracking focuses on the data itself, showing when tracked fields on records change, who made the change, and what the old and new values were.
Together, these features form the starting point for auditing in Salesforce. In this guide, we’ll look at what each one captures, where their limits are, and how teams can build on them to support stronger compliance, security, and day-to-day governance.
Setup Audit Trail: Tracking configuration changes
Setup Audit Trail is Salesforce’s built-in record of administrative changes in your orgs. It provides a read-only log of who did what, and when, at the configuration level, making it a useful starting point for security reviews, compliance audits, and troubleshooting unexpected behavior after a release. The feature is org-wide, enabled by default, and requires no setup.
Setup Audit Trail focuses on metadata and security changes, not record data. It answers questions like “Who modified this validation rule?”, “When were login policies updated?”, or “Who scheduled an org-wide data export through the Data Export Service?”
It doesn’t track individual report exports or detailed user activity. For this, you’ll need Event Monitoring. Setup Audit Trail also doesn’t capture field-level before-and-after values, and Salesforce only retains entries for a rolling window of around 180 days unless you export them manually.
What Setup Audit Trail captures
Setup Audit Trail records many of the configuration and security changes that shape how your org behaves in production. This includes common setup updates such as record type changes, custom object and field creation or deletion, automation edits, and some page layout changes. Coverage is broad but not exhaustive — whether a change appears in the trail depends on the setup area and how the change is made.
Setup Audit Trail historically captured updates to Workflow Rules and Process Builder, but both reached end of support on December 31, 2025. Existing automations continue to function, but Salesforce no longer provides customer support, bug fixes, or enhancements for these tools. Flow Builder is now Salesforce’s primary and preferred declarative automation platform, and its configuration changes are tracked in the audit trail. Approval process changes continue to be logged as well.
The trail also captures a wide range of security and access-related updates. This includes changes to password policies, session settings, login IP relaxations, network access rules, and identity configuration such as Single Sign-On. You’ll also see certain high-risk administrative actions, like org-wide data export and backup requests made through the Data Export Service — entries that often come up during audits or security reviews.
How much detail you get depends on the action. Audit trail entries typically show the timestamp, the user who made the change (and any delegate user), the setup area involved, and a short description of what happened. Some updates, such as certain profile or permission changes, may show values changing from X to Y. Most complex metadata changes don’t. An entry like “Modified validation rule” tells you that something changed, but not what changed inside the rule.
Understanding the retention and display limits
Salesforce retains Setup Audit Trail data for 180 days (six months). After that, entries are permanently deleted and can’t be recovered or extended using native Salesforce functionality.
The retention period clock starts ticking as soon as the change is made, not when someone looks at the audit trail. A configuration change made on May 1, for example, is gone for good after October 28, whether or not anyone ever reviewed it.
It’s also important to distinguish retention from visibility. In the Salesforce UI, the Setup Audit Trail shows just the 20 most recent entries at any given time. Older changes can still exist in the 180-day window, but they’re hidden from view unless you export them. If you’re relying on the UI alone, you’re seeing a very narrow slice of what’s actually happening in your org.
How to access and export the audit trail
In Salesforce Lightning, navigate to Setup using the gear icon in the top-right corner. In the Quick Find box, type “View Setup Audit Trail” and select the result. You’ll see a table displaying the 20 most recent administrative changes in reverse chronological order, with columns for Date, User, Action, Section, and Delegate User.
Access is limited to users with the View Setup and Configuration permission. This is included by default in the System Administrator profile, but not in standard user profiles, so access tends to be tightly controlled.
When you export the audit trail, Salesforce generates a CSV and stores it temporarily in the Audit Trail Export Dashboard, a separate Setup page. From there, you can download the file to your local machine for safekeeping or delete it if you no longer need it. If you do nothing, Salesforce automatically removes exported files after 72 hours.
The CSV mirrors what you see in the UI and doesn’t add much extra context. Timestamps are recorded in your org’s default timezone, and users are listed by display name rather than user ID. That’s often enough to answer basic “what changed and when” questions, but it can fall short when you’re trying to piece together a full audit trail or investigate changes over time.
Field History Tracking: Monitoring data changes
While the Setup Audit Trail focuses on how your org is configured, Field History Tracking shows what’s happening to the data inside it. It works at the record level, logging changes whenever a tracked field’s value is updated on an individual record. This makes it a go-to tool for answering questions about real business activity, such as why an Opportunity Amount increased, when an Account Owner was reassigned, or who closed a Case prematurely.
The big difference between Setup Audit Trail and Field History Tracking is that Setup Audit Trail tells you who modified the validation rule and Field History Tracking tells you who changed the field value that triggered it. If users suddenly can’t save Opportunities, Setup Audit Trail helps identify recent configuration changes. If leadership asks why revenue forecasts shifted, Field History Tracking shows exactly which records changed and when.
Unlike Setup Audit Trail, Field History Tracking is not enabled by default. You have to switch it on for each object and field, and Salesforce enforces a 20-field limit per object. Deciding what to track — and what to leave out — is a trade-off every team has to make.
Retention and storage constraints
Salesforce retains Field History Tracking records for around 18 months in the UI and up to 24 months when accessed via the API. After that, the data is automatically removed and can’t be recovered using standard Salesforce features.
If Field Audit Trail is enabled, those limits no longer apply. Instead, retention is controlled through configurable policies, allowing you to keep field history for significantly longer periods to meet audit and compliance requirements.
Field History Tracking data also doesn’t count toward your org’s data storage limits, which makes it useful for auditing without adding pressure to your storage allocation.
Which objects and fields support Field History Tracking?
Most standard objects — including Account, Contact, Opportunity, Case, and Lead — as well as all custom objects, support Field History Tracking in Salesforce. Yet, certain field types can’t be tracked, including formula fields, roll-up summary fields, auto-number fields, and system fields like Created By or Last Modified By.
Step-by-step setup for Field History Tracking
Enabling Field History Tracking in Salesforce requires access to Setup and appropriate configuration permissions (typically Customize Application). Tracking must be configured separately for each object and applies only from the moment it’s enabled — Salesforce can’t retroactively capture historical changes.
Here’s how to enable Field History Tracking in Lightning Experience:
Go to Setup → Object Manager.
Choose the object you want to track (e.g., Account, Opportunity, Case, or a custom object).
In the Details tab of the object you selected, click Edit.
Scroll down to the Object Features section, then click on the Track Field History check box.
Open Fields & Relationships, then click Set History Tracking.
Choose the fields to track. For most standard field types, Salesforce records both old and new values. For multi-select picklists and text fields over 255 characters (including Long Text and Rich Text), Salesforce records that the field was edited, but does not store the actual values. You can track up to 20 fields per object (standard and custom combined).
Click Save.
After enabling tracking, add the [Object Name] History related list to page layouts via Setup → Object Manager → Page Layouts. Without this step, Salesforce continues capturing history in the background, but users won’t see tracked changes on record pages.
Gearset Change Monitoring: Enhanced visibility for DevOps teams
Salesforce’s native audit tools provide essential baseline coverage, but they weren’t designed to support modern DevOps workflows with multiple environments, frequent releases, and long-term compliance requirements. As orgs scale, teams need visibility that goes beyond short retention windows, limited detail, and manual exports — without replacing the native audit mechanisms already in place.
Gearset’s Change Monitoring extends Salesforce’s native audit trail by continuously tracking metadata changes across environments and over time. Rather than focusing on individual events, it captures complete configuration snapshots, allowing teams to understand exactly what changed, when it changed, and how it differs from previous states. That context is what makes the difference when you’re investigating incidents, governing releases, or preparing for audits.
Change Monitoring works alongside Setup Audit Trail and Field History Tracking, filling in the gaps around retention, detail, and accountability — and giving teams confidence that no configuration change slips through unnoticed.
How Change Monitoring strengthens your audit trail
Where Salesforce’s Setup Audit Trail is limited to a fixed 180-day window, Gearset stores metadata snapshots without a built-in expiry. That means you can investigate incidents or demonstrate long-term compliance patterns months or even years after a change was made, not just while it’s still visible in the UI.
Coverage goes well beyond core metadata. Gearset tracks complex configurations like Salesforce CPQ components, Industries (Vlocity) DataPacks, Lightning record and app pages, and Flows, with clear before-and-after diffs that show exactly what changed. For developers, each monitoring run also includes automated static code analysis, helping surface security, performance, and code quality risks early.
Just as importantly, Change Monitoring shows where changes came from. It distinguishes between updates deployed through Gearset Pipelines and changes made directly in Salesforce via the UI, APIs, or other tools. That makes it far easier to spot unauthorized production changes, enforce change control, and maintain clear DevOps accountability.
Org Intelligence turns change history into answers teams can act on
Change Monitoring gives teams a complete, long-term record of how their Salesforce orgs change over time. Org Intelligence builds on that foundation by helping teams actually use that information in their planning and development.
Org Intelligence helps your team explore your org’s metadata quickly, and understand the current state of play in order to plan new or improved features. A key part of Org Intelligence is the Gearset Agent, an AI agent built on Gearset’s metadata analysis expertise. Gearset Agent lets teams ask questions about their org’s metadata and get clear answers, grounded in a deep understanding of your org.
Instead of manually combing through audit logs, diffs, and snapshots, teams can ask things like which Flows changed before an incident, whether a security setting was modified outside an approved deployment, or how a configuration evolved across environments over time.
It works across environments and time periods that Salesforce’s native audit tools don’t cover. It doesn’t replace data-level auditing or reporting. Its focus is metadata — how your org is built, how it’s changed, and how those changes relate to each other.
Where enhanced monitoring and insight really pays off
When something breaks in production — a validation rule starts firing unexpectedly or a Flow stops behaving — native tools can confirm that a change occurred. Gearset shows what changed.
Instead of assembling evidence manually for compliance and audit requirements, teams can lean on long-term configuration history, clear change attribution, and proof that quality gates were enforced as part of approved deployments. The result is less time spent preparing for audits and more confidence in the answers you give.
Maintain complete visibility across your org
Setup Audit Trail and Field History Tracking provide essential visibility into configuration and data changes. But, as orgs mature, their limitations become more obvious: fixed retention windows, inconsistent detail levels, and no native rollback or long-term comparison capabilities.
For teams scaling their DevOps processes, managing multiple environments, or operating under strict compliance frameworks, identifying changes isn’t enough. You need context, history, and control.
Gearset Change Monitoring and Org Intelligence extend Salesforce’s native audit capabilities with long-term visibility, deeper metadata insight, and clear change attribution — giving teams the context they need to investigate issues, prevent drift, and release with confidence.
Start a free 30-day trial or book a demo to see how leading Salesforce teams maintain full visibility into how their orgs change.
