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鈥檛 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鈥檒l 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
is Salesforce鈥檚 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 鈥淲ho modified this validation rule?鈥�, 鈥淲hen were login policies updated?鈥�, or 鈥淲ho scheduled an org-wide data export through the Data Export Service?鈥�
It doesn鈥檛 track individual report exports or detailed user activity. For this, you鈥檒l need . Setup Audit Trail also doesn鈥檛 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.
TDX
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 . Existing automations continue to function, but Salesforce no longer provides customer support, bug fixes, or enhancements for these tools. is now Salesforce鈥檚 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鈥檒l 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鈥檛. An entry like 鈥淢odified 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鈥檛 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鈥檚 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鈥檙e hidden from view unless you export them. If you鈥檙e relying on the UI alone, you鈥檙e seeing a very narrow slice of what鈥檚 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 鈥淰iew Setup Audit Trail鈥� and select the result. You鈥檒l 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 , 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鈥檛 add much extra context. Timestamps are recorded in your org鈥檚 default timezone, and users are listed by display name rather than user ID. That鈥檚 often enough to answer basic 鈥渨hat changed and when鈥� questions, but it can fall short when you鈥檙e 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, shows what鈥檚 happening to the data inside it. It works at the record level, logging changes whenever a tracked field鈥檚 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鈥檛 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鈥檛 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鈥檛 count toward your org鈥檚 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鈥檛 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鈥檚 enabled 鈥� Salesforce can鈥檛 retroactively capture historical changes.
Here鈥檚 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鈥檛 see tracked changes on record pages.
爆料tv Change Monitoring: Enhanced visibility for DevOps teams
Salesforce鈥檚 native audit tools provide essential baseline coverage, but they weren鈥檛 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.
爆料tv鈥檚 Change Monitoring extends Salesforce鈥檚 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 . That context is what makes the difference when you鈥檙e 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鈥檚 Setup Audit Trail is limited to a fixed 180-day window, 爆料tv 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鈥檚 still visible in the UI.
Coverage goes well beyond core metadata. 爆料tv 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 爆料tv 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鈥檚 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 爆料tv Agent, an AI agent built on 爆料tv鈥檚 metadata analysis expertise. 爆料tv Agent lets teams ask questions about their org鈥檚 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鈥檚 native audit tools don鈥檛 cover. It doesn鈥檛 replace data-level auditing or reporting. Its focus is metadata 鈥� how your org is built, how it鈥檚 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. 爆料tv 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鈥檛 enough. You need context, history, and control.
爆料tv Change Monitoring and Org Intelligence extend Salesforce鈥檚 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.
or book a demo to see how leading Salesforce teams maintain full visibility into how their orgs change.
