Salesforce Setup Audit Trail: The Complete Admin Guide

The complete admin guide to the Salesforce Setup Audit Trail: what it tracks, how to query it with SOQL, its key limitations, and how to fill the gaps.

Someone changed a profile in your org yesterday. You found out from a support ticket.

This happens every day in Salesforce orgs of every size. The Salesforce Setup Audit Trail exists to prevent exactly this, but most admins treat it as a last resort: something you dig into after something breaks. That reactive posture is the problem.

This guide covers everything you need to know about Setup Audit Trail: what it tracks, how to find it, how to query it with SOQL, its real limitations, and what to do about those limitations. By the end, you'll have a clear picture of what your org is telling you every day, and what it's keeping from you.


What Is the Setup Audit Trail?

The Setup Audit Trail is a built-in Salesforce feature that records every configuration change made in your org's Setup. It captures what changed, who changed it, when, and from which IP address.

It is not the same as Field History Tracking. Field History Tracking records changes to data values in records (the "Opportunity Stage changed from Prospecting to Closed Won" kind of change). The Setup Audit Trail records configuration changes: profiles, permission sets, security settings, flows, Apex classes, connected apps, and more.

If someone touches anything in Setup, it appears in the Setup Audit Trail.

The underlying Salesforce object is called SetupAuditTrail. It has been available since API version 15.0.


Where to Find It in the UI

  1. Click the gear icon in the top-right corner of any Salesforce page
  2. Select Setup
  3. In the Quick Find box, type View Setup Audit Trail
  4. Click Setup Audit Trail

The default view shows the last 20 changes. To see more, click Download to export up to 180 days of history as a CSV file.

The columns you'll see:

  • Date: Timestamp of the change, in your org's timezone
  • User: The full name of the user who made the change
  • Action: A short description of what was done
  • Section: The Setup area where the change was made (more on this below)
  • Delegate User: If an admin was logged in as another user when the change was made, the delegating admin appears here

The Section field is the most useful for filtering. Common section values include Security Controls, Manage Users, Manage Roles, Apex Class, Flow, Custom Object, OAuth, Identity, and Single Sign-On Settings.


How to Query the Setup Audit Trail with SOQL

The real power of SetupAuditTrail is that you can query it through the API, which means you can automate monitoring, build reports, and integrate it with external tools.

Basic query to see recent changes:

SELECT Action, Section, CreatedDate, CreatedBy.Name, Display, DelegateUser
FROM SetupAuditTrail
ORDER BY CreatedDate DESC
LIMIT 100

To filter by a specific section:

SELECT Action, Section, CreatedDate, CreatedBy.Name, Display
FROM SetupAuditTrail
WHERE Section = 'Security Controls'
ORDER BY CreatedDate DESC

To find all changes made by a specific user in the last 30 days:

SELECT Action, Section, CreatedDate, Display
FROM SetupAuditTrail
WHERE CreatedBy.Name = 'Jane Smith'
AND CreatedDate = LAST_N_DAYS:30
ORDER BY CreatedDate DESC

To find all profile changes:

SELECT Action, Section, CreatedDate, CreatedBy.Name, Display
FROM SetupAuditTrail
WHERE Section = 'Manage Users'
AND Action LIKE '%profile%'
ORDER BY CreatedDate DESC

The Display field contains a plain-English description of the change. It often gives you more context than Action alone. For a profile change, Display might read: "Changed profile System Administrator: Login Hours changed."


What the Setup Audit Trail Actually Tracks

The Setup Audit Trail covers a broad range of Salesforce configuration areas. Here is what you can reliably find:

Security and access: Changes to profiles, permission sets, permission set groups, sharing rules, field-level security, password policies, session settings, login IP ranges, network access rules, and certificate management.

Identity and authentication: MFA requirement changes, SSO configuration updates, OAuth settings, external authentication providers, and identity provider configuration.

Automation: Flows (activation, deactivation, deletion), Apex classes and triggers (save or compile events), workflow rules (end-of-support December 2025, but historical records remain), Process Builder (same), and Validation Rules.

Data model: Custom object creation and deletion, custom field creation and modification, record types, page layouts, and approval processes.

Integrations: Connected apps, named credentials, remote site settings, and external data sources.

Users: User creation, profile assignment, role assignment, permission set assignment, and user deactivation.

For each category, the Section value tells you which area of Setup was touched. Security changes tend to appear under "Security Controls", "Identity", "OAuth", or "Manage Users". Infrastructure changes appear under "Apex Class", "Flow", "Custom Object", and similar.


The Real Limitations of Setup Audit Trail

This is where most guides stop telling you the full story.

1. 180-day retention only. Salesforce stores 180 days of Setup Audit Trail data in the standard object. After 180 days, the records are purged. If your compliance team needs a year of audit history, the standard Setup Audit Trail will not give it to you.

2. The UI only shows 20 rows. The default view shows the last 20 changes. To see anything beyond that, you have to export a CSV or write a SOQL query. Most admins never get past those first 20 rows.

3. No alerting. The Setup Audit Trail is passive. It records changes, but it does not notify you when a critical change happens. If MFA gets disabled at 2am, nothing alerts you. You find out the next morning, or the next week, or the next time someone runs a security review.

4. No severity classification. Every change looks the same in the raw log. A Critical change like "MFA enforcement disabled for all users" appears in the same format as a Low-severity change like "Dashboard renamed." Without context, you have to manually evaluate every record to understand what matters.

5. Data changes are not tracked. The Setup Audit Trail tracks configuration changes only. It does not track changes to record data. If an admin modifies an Account record directly, that does not appear here. Field History Tracking covers record-level changes on specific objects.

6. No diff view. You can see that a profile changed, but not exactly which permissions were added or removed. You see the event ("Profile changed"), not the delta (which specific permission was added or removed).

7. API-only changes may appear differently. Changes made directly via the Metadata API or during a deployment with Change Sets or DevOps Center appear in the Setup Audit Trail, but the user shown is typically the deploying admin, not the developer who made the change in sandbox. This makes traceability harder in teams using source-driven development.


What to Do With These Limitations

Given these gaps, a layered approach to monitoring works best.

For the 180-day retention gap: Export your Setup Audit Trail to a spreadsheet or your SIEM on a regular cadence (weekly at minimum), before records age out. If you have Salesforce Shield, Field Audit Trail extends data retention for field history up to 10 years, though this covers field-level data, not Setup changes.

For the no-alerting gap: Build a Salesforce Flow that runs daily, queries the SetupAuditTrail object for high-risk section values (Security Controls, OAuth, Identity), and sends an email or Slack notification if anything appears in the last 24 hours. It is not perfect (Flows can be deactivated), but it is better than no alerting.

For the severity classification gap: Maintain a simple reference document that maps Section values to risk levels. Security Controls changes are Critical. Manage Users changes are High. Flow changes are Medium. Dashboard changes are Low. This does not need to be complex. It just needs to exist so that when you review the log, you know where to focus.

For daily automated monitoring and classification: Tools like AuditForce connect to your SetupAuditTrail via the API, apply a configurable severity rules engine to every change, and deliver a daily digest categorized by Critical, High, Medium, and Low. You see what matters first, every morning, without digging through raw CSV exports. For a deeper look at how to build this routine, see How to Monitor Salesforce Org Changes and The 5 Salesforce Security Changes You Need to Monitor.


Making Setup Audit Trail Part of Your Routine

The admins who get the most value from Setup Audit Trail treat it like email: something you check daily, not after a fire starts.

A practical weekly routine:

  1. On Monday morning, review the last 7 days of Security Controls and Manage Users changes
  2. After any deployment or change window, confirm the expected changes (and only the expected changes) appear in the log
  3. Before any user reports a permissions issue, check the Audit Trail first. It is usually faster than asking around.

The goal is not to catch every possible change the moment it happens. The goal is to build enough visibility that surprises become rare, and when something does go wrong, you have a complete record of what changed and when.

That record is worth protecting. Export it. Monitor it. And build a routine around it before you need it.