What Gets Logged in the Salesforce Audit Trail (And What Doesn't)
What the Salesforce audit trail actually logs, what it misses, and how to fill the gaps so you're not flying blind between what's tracked and what isn't.
You get a support ticket. A user can't access a record they could reach last week. You open the Setup Audit Trail to see what changed. The audit trail shows nothing relevant for that record.
That's not a bug. Knowing what gets logged in the Salesforce audit trail — and what doesn't — is the first step to building reliable change visibility in your org. The Setup Audit Trail was never designed to track data-level changes. This post covers all of it: the ten categories it tracks, the eight gaps that catch admins off guard, and how to handle each gap.
What the Salesforce Audit Trail Actually Tracks
The Setup Audit Trail captures configuration changes made in your org's Setup. It does not capture record data changes. Everything in the list below appears in the SetupAuditTrail object, queryable via SOQL and visible in Setup under View Setup Audit Trail.
1. Security and Access Controls
Every change to how users authenticate and what they can access:
- Profile modifications (login hours, login IP ranges, permission changes)
- Permission set creation, deletion, and assignment
- Permission set group changes
- Field-level security changes
- Sharing rule additions and removals
- Password policy changes
- Session settings (timeout, IP locking, HTTPS requirements)
- Network access settings
These appear under the Security Controls and Manage Users sections in the Setup Audit Trail.
2. Identity and Authentication
Changes to how users prove who they are:
- MFA requirement changes
- SSO configuration updates (identity provider settings, certificate changes)
- OAuth settings
- External authentication providers
- Identity provider (IdP) configuration
These appear under the Identity and Single Sign-On Settings sections.
3. Automation
Changes to anything that runs automatically in your org:
- Flow activation and deactivation
- Flow creation and deletion
- Apex class saves and compilation events
- Apex trigger saves
- Workflow rules (historical records remain even after end-of-support in December 2025)
- Process Builder actions
- Validation rule creation and modification
Flow changes appear under the Flow section. Apex changes appear under Apex Class and Apex Trigger.
4. Data Model
Structural changes to your objects and fields:
- Custom object creation and deletion
- Custom field creation, modification, and deletion
- Record type changes
- Page layout assignments
- Approval process configuration
These appear under Custom Object, Custom Field, and related sections.
5. Integrations and External Access
Changes to how external systems connect to your org:
- Connected app creation and modification
- OAuth scope changes on connected apps
- Named credential changes
- Remote site settings (CSP trusted sites)
- External data source configuration
Connected app changes appear under the OAuth section.
6. Users
Changes to the users themselves:
- User creation
- Profile assignment changes
- Role assignment changes
- Permission set assignments and removals
- User deactivation and reactivation
- Delegated administrator assignments
Most user changes appear under Manage Users.
7. Roles and Hierarchy
Changes to your org's role structure:
- Role creation and deletion
- Role hierarchy modifications
- Role name changes
These appear under Manage Roles.
8. Certificates and Keys
Changes to authentication certificates and encryption keys:
- Certificate uploads
- Certificate expiration events
- Key rotation events
These appear under Certificate and Key Management.
9. Territory Management
If you use Enterprise Territory Management:
- Territory model activation and deactivation
- Territory rule changes
- Territory assignment changes
10. Custom Settings and Metadata
Changes to configuration data stored as custom settings or custom metadata:
- Custom setting field value changes (in some configurations)
- Custom metadata type record changes made through Setup
What the Salesforce Audit Trail Does NOT Log
This is where most admin monitoring strategies break down. The gaps below are the cases where something changes in your org and the Setup Audit Trail shows nothing.
| Gap | What This Means | What to Use Instead |
|---|---|---|
| Record data changes | An Account name changed, an Opportunity was deleted, a contact's email was modified — none of this appears | Field History Tracking on individual objects |
| Data imports and mass updates | Data Loader uploads, external system writes, bulk API operations | Event Monitoring (API usage logs) or Data Change Event platform events |
| Report and dashboard views | Who ran a report, who viewed a dashboard, what data was exported | Event Monitoring (Report Export Events) |
| List view exports | Users exporting data from list views to Excel | Event Monitoring |
| Login events | Who logged in, from where, at what time, from what browser | Login History (Setup > Login History) or Event Monitoring |
| API calls and data queries | API clients reading or writing data in bulk | Event Monitoring (API Total Usage Events) |
| Exact permission diffs | You can see that a profile changed, but not which specific permissions were added or removed | Metadata API snapshots with diffing |
| Sandbox-to-production deployments (detailed) | Deployments appear attributed to the deploying admin, not the developer who made the change in sandbox | Change set history or your DevOps tooling |
The permission diff gap deserves specific attention. When a profile is modified, the Setup Audit Trail shows an entry like "Changed profile System Administrator." It does not show which permissions changed. If you want to know whether ModifyAllData was added or removed, you need a metadata snapshot of the profile before and after the change and a diff between them.
The 180-Day Retention Cliff
The Setup Audit Trail retains 180 days of data. Records older than 180 days are permanently deleted by Salesforce. There is no recycle bin for audit trail records.
This matters more than most admins realize until a compliance audit arrives asking for change history from 8 months ago. The answer then is that the data is gone.
The practical fix: export your Setup Audit Trail monthly and store the exports somewhere persistent (a shared drive, your SIEM, a simple S3 bucket). The export is a CSV containing all available fields. A monthly export cadence gives you a rolling archive that extends well beyond Salesforce's 180-day window.
SELECT Action, Section, CreatedDate, CreatedBy.Name, Display, DelegateUser
FROM SetupAuditTrail
ORDER BY CreatedDate DESC
LIMIT 2000
Run this via SOQL in Workbench or via the Tooling API. For the full 180-day window, use LAST_N_DAYS:180 as a filter.
Setup Audit Trail vs. Field History Tracking vs. Event Monitoring
These three tools cover different categories of Salesforce activity. Knowing which one to use for which question saves time when something goes wrong.
| Question | Tool |
|---|---|
| Who changed a profile or permission set? | Setup Audit Trail |
| Who activated or deactivated a Flow? | Setup Audit Trail |
| Who changed the value of this Opportunity field? | Field History Tracking |
| Who ran this report last month? | Event Monitoring |
| Who logged in from this IP address? | Login History |
| Who exported data from this list view? | Event Monitoring |
| What exact permissions changed in this profile? | Metadata API diff |
| Who connected this external app? | Setup Audit Trail (OAuth section) |
Field History Tracking is enabled per-object and per-field in Setup. It tracks up to 20 fields per object and retains history for 18 months (up from the previous 18-month limit with Salesforce Shield). Standard objects like Account, Contact, Lead, and Opportunity support it out of the box.
Event Monitoring is a paid Salesforce add-on (available with Event Monitoring licenses or as part of Salesforce Shield). It covers the gaps that neither the Setup Audit Trail nor Field History Tracking address: login behavior, API usage, report exports, and similar.
How to Export the Setup Audit Trail
From the UI:
- Go to Setup, type "Audit Trail" in Quick Find
- Click View Setup Audit Trail
- Click Download — this exports up to 180 days as a CSV
The UI export gives you the full available history. The default view only shows the last 20 rows, which is misleading. Always export when you need complete data.
Via SOQL:
SELECT Action, Section, CreatedDate, CreatedBy.Name, Display, DelegateUser
FROM SetupAuditTrail
WHERE CreatedDate = LAST_N_DAYS:30
ORDER BY CreatedDate DESC
Key fields to understand:
Action: Short code for what happened (e.g., "PermSetAssign")Section: The Setup area where the change occurred (e.g., "Security Controls")Display: Plain-English description of the change — this is the most readable fieldDelegateUser: Populated when an admin was logged in as another user when the change was madeCreatedBy: The user who made the changeCreatedDate: When the change occurred, stored in UTC
The Display field is particularly useful for filtering. For a permission set assignment, it might read: "Assigned permission set Data Export Permission to jsmith@company.com." That context is easier to act on than the raw Action code.
Closing the Gaps With Continuous Monitoring
The Setup Audit Trail is a strong foundation, but it has three operational problems: you have to remember to check it, everything looks equally important in the raw log, and the 180-day window eventually closes.
A continuous monitoring approach addresses all three. AuditForce queries your SetupAuditTrail daily via the Salesforce API, applies a severity rules engine to classify every change as Critical, High, Medium, or Low, and delivers the results in a daily digest. Security-critical changes (MFA configuration, IP restrictions, SSO settings, OAuth changes) are classified as Critical by default and trigger immediate notifications rather than waiting for the next digest. The rules engine is configurable: if your org has specific administrative patterns that produce false positives for a particular rule, you can adjust the classification without losing coverage for everything else.
For the permission diff gap and the data-change gap, see How to Monitor Salesforce Org Changes for a broader framework that covers all monitoring layers, and The 5 Salesforce Security Changes You Need to Monitor for the highest-priority categories to watch in the Setup Audit Trail.
FAQ
Does the Setup Audit Trail log Salesforce Flow runs? No. The Setup Audit Trail logs when a Flow is activated, deactivated, created, or deleted. It does not log individual Flow executions. For Flow execution tracking, use Debug Logs or the Flow Error Email alerts (Setup > Flow Error Emails).
Does the Setup Audit Trail log changes made by the Salesforce support team? Yes. If Salesforce support is granted login access to your org (via Setup > Company Information > Grant Login Access), any Setup changes they make appear in the audit trail attributed to the Salesforce support user.
Can you query the Setup Audit Trail via the REST API?
Yes. The SetupAuditTrail object is available via both the SOAP API and REST API. The SOQL syntax is standard. For bulk exports, the Bulk API or Tooling API is more efficient than the standard REST API.
What happens to Setup Audit Trail data if you delete a user?
The audit trail records are retained even after a user is deleted. The CreatedBy.Name field will still show the user's name. The records are not purged when the user is removed.