How to Monitor Salesforce Org Changes (Before Something Goes Wrong)

How to monitor Salesforce org changes before they cause damage. Covers native Salesforce tools, manual routines, and how to move to continuous monitoring.

A flow gets deactivated on a Tuesday afternoon. The sales team stops getting their lead routing notifications. By Thursday, three deals have been worked by the wrong reps. By Friday, you're in a meeting explaining what happened.

The worst part of failing to monitor Salesforce org changes: the change took four seconds to make. Finding it took four days.

This scenario plays out in Salesforce orgs every week. Not because admins are careless, but because most orgs have no continuous monitoring in place. Changes happen, nobody is watching, and the only way you find out is when something breaks.

This guide shows you how to monitor Salesforce org changes before they cause damage, starting with what Salesforce gives you natively and building toward something that actually keeps you informed.

Why Org Changes Are Hard to Track

Salesforce orgs are living systems. At any given moment, changes are coming from multiple directions: admins making configuration updates, developers deploying from sandbox, automated deployments from CI/CD pipelines, managed package upgrades, and Salesforce's own seasonal releases.

Each of these can modify profiles, permissions, flows, sharing rules, connected apps, and security settings. Each can affect users in ways that range from invisible to catastrophic.

The challenge is not that Salesforce lacks audit data. The SetupAuditTrail object records every configuration change made in Setup, including who made it, when, and from which IP. The challenge is that this data requires active review. Nothing in Salesforce proactively tells you that a critical change happened.

Most admins check the Setup Audit Trail reactively: after something breaks, after a user complains, or during a quarterly security review. By that point, the damage is already done.

What You Can Monitor Natively in Salesforce

Before reaching for third-party tools, understand what Salesforce gives you out of the box.

Setup Audit Trail

The primary tool for tracking configuration changes. Covers:

  • Profile and permission set changes
  • Security setting modifications (MFA, session settings, IP restrictions)
  • Flow activation and deactivation
  • Connected app configuration
  • User creation, deactivation, and role changes
  • Apex class and trigger deployments

Access it through Setup, Quick Find, "View Setup Audit Trail." The default UI shows only the last 20 changes. To see more, download up to 180 days as a CSV, or query the SetupAuditTrail object directly via SOQL.

Limitation: it records changes but does not alert you to them.

Event Monitoring

Salesforce Shield's Event Monitoring captures nearly 50 event types including login history, data exports, API calls, and report runs. It goes deeper than Setup Audit Trail for user activity (who ran a report, who exported data, who made API calls).

Event Monitoring requires a Salesforce Shield license or an Event Monitoring add-on. It is not available in all editions.

Health Check

A built-in security assessment tool that scores your org's security configuration against Salesforce's recommended baseline. It flags settings that fall below the recommended threshold: session timeout set too long, MFA not enforced, login IP ranges not set.

Health Check shows your current state, not your change history. If you run it and your score dropped from 85 to 60 since last month, it does not tell you why. For that, you need the Audit Trail.

Permission Set and Profile Change Reports

Via SOQL or custom reports, you can query PermissionSet, Profile, ObjectPermissions, and FieldPermissions to snapshot the state of your permission model at a point in time. Running these snapshots regularly and comparing them over time reveals permission drift.

This approach is manual and time-consuming, but it is available to every Salesforce admin regardless of edition or budget.

The Four Categories of Changes That Matter Most

Not all changes carry the same risk. When you're monitoring an org, these four categories deserve the most attention.

1. Security setting changes

Any modification to MFA requirements, session settings, login IP ranges, password policies, or single sign-on configuration can expose your org to unauthorized access. These changes can happen silently and have immediate impact.

In the Setup Audit Trail, these appear under the Security Controls, Identity, and Single Sign-On Settings sections.

2. Access and permission changes

Profile modifications, permission set assignments, and sharing rule changes alter who can see and do what across your org. Permissions creep silently over time: a quick "give them access just for this project" that never gets revoked.

These appear under Manage Users, Manage Roles, and Profiles in the Audit Trail.

3. Automation changes

Flow activation and deactivation, Apex trigger modifications, and scheduled job changes can break critical business processes instantly. A flow that sends a contract for signature can be deactivated in seconds. You may not notice for days if the deals in progress are still moving through other stages.

These appear under Flow and Apex Class sections.

4. Integration changes

Connected app configuration changes, named credential updates, and remote site setting modifications affect every integration your org has with external systems. Removing a named credential can break a nightly data sync. Changing a connected app's OAuth scope can lock out a third-party tool.

These appear under OAuth and Connected Apps sections.

Building a Manual Monitoring Routine

If you are not ready to automate yet, a structured manual routine is significantly better than no routine.

Daily (10 minutes): Query the SetupAuditTrail for the last 24 hours, filtered to Security Controls, OAuth, and Manage Users sections. If anything appears, investigate immediately.

SELECT Action, Section, CreatedDate, CreatedBy.Name, Display
FROM SetupAuditTrail
WHERE Section IN ('Security Controls', 'OAuth', 'Manage Users', 'Identity')
AND CreatedDate = TODAY
ORDER BY CreatedDate DESC

Weekly (30 minutes): Review all Setup Audit Trail changes from the past 7 days across all sections. Look for patterns: the same admin making many changes in a short window, changes made outside business hours, or multiple permission set assignments.

After every deployment: Cross-reference what your change set or DevOps Center deployment was supposed to change against what actually appeared in the Audit Trail. Unexpected changes in the Audit Trail after a deployment mean something in the deployment did not go as planned.

Monthly: Export the full 30-day Audit Trail to CSV and store it somewhere outside Salesforce. This builds a running archive that goes beyond the 180-day native retention limit.

Where Manual Monitoring Breaks Down

The manual routine above works well in small orgs with one or two admins and infrequent changes. It breaks down quickly in several common scenarios.

Volume: In an active org, dozens of changes can happen in a single day. Reviewing them all manually takes longer than 10 minutes and requires consistent discipline across weeks and months.

Off-hours changes: The riskiest changes often happen outside business hours: a contractor working late, an automated deployment running at midnight, a bad actor with stolen credentials. Manual monitoring only catches what you actively look for, and nobody is looking at 2am.

Managed packages: When a managed package updates, it can modify permissions, sharing rules, and settings across your org. These changes appear in the Audit Trail but can be difficult to distinguish from intentional admin changes.

Team environments: In orgs with multiple admins or a developer team, manual monitoring requires coordination. If each person assumes someone else is watching, nobody is watching.

The classification problem: Even when you find a change, deciding how serious it is requires context. Is a profile modification to add "View All" on Contacts a routine update or a significant permissions change? Without a framework for answering that question quickly, review sessions become slow and inconsistent.

Moving to Continuous Monitoring

Continuous monitoring means your org is being watched around the clock, with changes classified and surfaced to you on a regular cadence, without requiring you to remember to check.

The core components of a continuous monitoring setup:

Automated ingestion: The SetupAuditTrail API is queried on a regular schedule (daily, or more frequently for higher-risk environments) so changes are captured as they happen.

Severity classification: Every change is evaluated against a rules framework that maps Section values and Action types to severity levels. Security Controls changes become Critical. Flow changes become Medium. Dashboard changes become Low.

Digest delivery: Instead of digging through raw logs, you receive a daily summary that leads with the highest-severity changes. You see what matters most first, every morning.

Immediate alerts for critical changes: If a Critical change happens (MFA disabled, security settings modified, admin user deactivated), you are notified immediately rather than waiting for the next morning's digest. For a breakdown of which changes warrant immediate attention, see The 5 Salesforce Security Changes You Need to Monitor.

This is exactly what AuditForce is built to do: continuous ingestion of your SetupAuditTrail, automatic severity classification via a configurable rules engine, a daily email digest organized by Critical, High, Medium, and Low, and real-time alerts for Critical changes. Every change is human-readable, not raw API output.

The Standard You Should Hold Yourself To

The goal of org monitoring is not to catch every change the moment it happens. It is to be able to answer these questions at any time:

  • What changed in my org in the last 24 hours?
  • What changed in the last 7 days that was security-related?
  • Did anyone modify profiles or permission sets this week?
  • When was the last time a Critical security setting was changed?

If you can answer all four in under two minutes, your monitoring is working. If answering them requires a CSV export, a SOQL query, and an email to your team, your monitoring needs work.

Start with the manual routine. Build the habit. Then automate it so the habit doesn't depend on your memory.