TL;DR
- Salesforce Event Monitoring tracks user activity well — logins, API calls, report exports — but it doesn't log the config change that actually broke your org.
- No single native tool sees everything: Event Monitoring, the Setup Audit Trail, and Field History Tracking each cover a different layer, and all of them log silently, AKA: with no alerts.
- The real pain is in notification and retention — the audit trail waits 180 days for someone to go looking, and nothing tells you when a permission set changes at midnight.
- The fix is layering: Event Monitoring for behavior, audit logs for config, change tracking for accountability, and real-time alerts so you find out before the support ticket does.
******
A user can't access a record they could reach last week.
You open Event Monitoring to find out what happened.
You see their logins.
You see their API calls.
You see, in gloriously granular detail, every report they exported.
What you don't see? The very thing you actually need: the permission set someone modified on Tuesday that rug-pulled their access.
This is a sneakier problem with Salesforce Event Monitoring. It's a honest-to-goodness effective tool, when pointed at one half of your org. Most teams discover the other half is uncovered at the worst possible moment, in the middle of an incident, with a stakeholder tapping their foot.
Here's what each native tool sees, where the gaps are, and how to layer them so something is watching the part that breaks.
What Salesforce Event Monitoring actually tracks
Event Monitoring is built to answer questions about behavior. Who logged in, from where, and when. Which APIs got called and how often. Who ran which report, who exported it, who hit a page. It's a paid add-on, available with Event Monitoring licenses or as part of Salesforce Shield, and it covers the gaps that login history and basic tooling can't: login behavior, API usage, report exports, and similar runtime activity.
For security and performance work, this can be super valuable. If you're investigating credential misuse, watching for anomalous data exports, or tuning API consumption, Event Monitoring is the right instrument. With Shield, it adds real-time event monitoring and Transaction Security policies that can block transactions, require MFA, or send notifications based on runtime events.
But notice what every one of those events has in common… they're things a user did at runtime.
Event Monitoring watches people using the org not changing the org.
Where the Salesforce audit log picks up — and where it stops
That's the job of a different tool: the Setup Audit Trail.
This is the Salesforce audit log most admins reach for when something configuration-level goes haywire. It's a read-only record of who did what and when at the configuration level — org-wide, enabled by default, no setup required.
The underlying SetupAuditTrail object records configuration changes across security settings, profiles, permission sets, flows, Apex classes, connected apps, sharing rules, and the like.
So the permission set change that broke your user's access? Oh, it's in there. Which sounds like the gap is solved — until you hit the two limits that catch admins off guard.
First, retention.
Salesforce only retains audit trail entries for a rolling window of roughly 180 days unless you export them manually. Only the last 20,000 entries are stored, which in a busy org is well under six months. If you're investigating something that started before that window, or assembling history for a SOC 2 or HIPAA audit, the record you need may already be gone.
Second — and this is the one that actually hurts — the audit log doesn't capture before-and-after values for everything, and it tells you nothing on its own. It doesn't capture field-level before-and-after values, and for record-level data changes you need Field History Tracking instead, which is yet another separate tool with its own 20-fields-per-object ceiling. So now you're stitching together three native features — Event Monitoring for behavior, Setup Audit Trail for config, Field History Tracking for record data — none of which talks to the others, to reconstruct a single incident. Gearset
Why Salesforce alerts are the gap nobody scopes for
Here's the part that turns a visibility problem into an operational one. Every tool above is a log. Logs are passive. They sit there and wait.
There's no notification when MFA gets disabled. No alert when a permission set is modified at midnight. No email when someone adds an OAuth app or widens a sharing rule. The change is logged in the Setup Audit Trail, and it waits there until someone goes looking. And in most orgs, that "someone goes looking" moment happens after something has already gone wrong.
This is the failure mode… Salesforce records the change but nothing surfaces the change to a human in time to matter. Salesforce records every configuration change made in your org. It tells you about none of them.
Transaction Security policies can fire real-time alerts on certain runtime events, but they're scoped to the event types Shield monitors and require configuration per policy.
For the broad surface of everyday config changes — the profile edit, the flow that got deactivated, the validation rule someone tweaked before a release — the native answer is still "check the log later." Real-time Salesforce alerts on configuration changes aren't something you get out of the box; they're something you have to build, and most teams haven't.
What real Salesforce change tracking looks like
Put the gaps together and the shape of the fix is clear. Complete visibility into a Salesforce org can be carved up into four jobs:
- Behavior — who's using the org and how. This is Event Monitoring's strength; keep it for security and performance.
- Configuration — who changed what in Setup. The Setup Audit Trail covers this, within its retention limit.
- Record data — how field values evolved. Field History Tracking, within its field cap.
- Notification — being told when any of the above happens, in time to act. This is the layer Salesforce leaves to you.
The first three are about recording. The fourth — alerting and durable retention — is where native tooling runs out, and it's the one that determines whether you find out about a change from a dashboard or from a furious stakeholder.
This is the layer Sweep is built for.
Where Salesforce's native audit history stops at roughly six months, Sweep captures every configuration change across every environment in real time and stores it indefinitely — enough to stay audit-ready for SOC 2, HIPAA, GDPR, and SOX. And because it's watching continuously rather than logging passively, Sweep's Monitoring Agent scans for risks and best-practice violations and pushes instant notifications when a new violation occurs, so the team resolves issues before they disrupt operations.
Those proactive alerts land in Slack or email, surfacing conflicts during build and UAT — long before users feel the impact in production.
The difference is the difference between the two stories at the top of this post. In one, you open a log after the ticket comes in and start reconstructing what happened. In the other, you got a Slack message the moment the permission set changed at midnight — and the ticket never got filed. 😎
