Admin Guide · Updated April 2026

How to Audit Your Salesforce Org: The Complete 2026 Checklist

10-minute read
April 28, 2026
OrgPilot Team

Org debt compounds quietly. A neglected Salesforce org develops security gaps, broken automation, and license waste that no one notices until it's expensive to fix. This 10-point checklist covers everything a Salesforce admin should audit — and why each check matters.

Why you need to audit your Salesforce org

Most Salesforce orgs were built incrementally — one project, one consultant, one admin at a time. Without periodic audits, the result is a system carrying years of unintended technical debt. Three reasons this compounds into real problems:

Org debt compounds

Every unused field, every inactive workflow, every duplicated permission set makes future changes harder. Orgs that skip annual audits spend 3× longer on projects 3 years later.

🔒

Security risk is invisible

Permission creep happens gradually. A profile given Modify All for "a quick project" never gets cleaned up. Until it does, it's a data breach waiting to happen.

📉

Performance degrades silently

Wide objects with hundreds of unused fields slow page load. Unbounded SOQL in broken flows burns API limits. Users blame Salesforce when the real problem is org hygiene.

The Salesforce org audit checklist

Work through these 10 areas systematically. Each includes what to look for and why it matters. Severity ratings reflect typical impact when the issue is present.

1
Medium risk

Unused custom fields (field bloat)

Salesforce objects accumulate custom fields from past projects, abandoned initiatives, and consultants who left. Fields that haven't stored data in 90+ days are dead weight — they slow page loads, confuse users with irrelevant inputs, and eat into field limits on older orgs.

What to check
  • Run a field usage report via Setup → Fields & Relationships on each major object
  • Flag any field with 0 populated records in the last 90 days
  • Check formula fields referencing deleted or inactive fields (they silently return blank)
  • Look for near-duplicate fields (e.g., three "source" fields on Lead)
  • Verify all fields appear on at least one active page layout
2
High risk

Wide permission sets (security risk)

Permission creep is the most dangerous and most common org health issue. A permission set granted "Modify All Data" to a sales rep for a one-week project — and never revoked — is a standing security vulnerability. Salesforce security audits start here.

What to check
  • List all permission sets with "Modify All Data" or "View All Data" checked
  • Check who is assigned to each high-privilege permission set (Setup → Permission Set Assignments)
  • Flag any non-System Administrator user with API Enabled + Modify All
  • Look for permission sets that haven't been modified in 2+ years but still have active assignments
  • Audit "Manage Users" permission — it effectively grants admin-level access
3
High risk

Broken and inactive automation (Flows, Workflow Rules)

Every inactive or erroring automation is a landmine. Flows that error silently fail data operations and leave records in inconsistent states. Legacy Workflow Rules that overlap with new Flows create ordering conflicts that are nearly impossible to debug without knowing both exist.

What to check
  • Open Flow → All Flows and filter by Status = "Inactive" — every inactive flow needs a disposition decision
  • Check the Apex Exception Log for recurring flow errors (Setup → Apex Exception Log)
  • List all active Workflow Rules and identify any that duplicate Flows on the same object
  • Look for Process Builder processes — they're legacy and will be retired by Salesforce
  • Audit interview records for Paused flow instances older than 30 days
4
Low-Medium risk

Undocumented custom objects

Custom objects created for integrations, one-off projects, or by contractors often persist long after their purpose has expired. An undocumented custom object with no description, no owner, and no linked flows is dead metadata taking up schema space — and a sign that your org governance is weak.

What to check
  • Open Setup → Object Manager → filter by Type = "Custom Object"
  • Flag any object missing a description or deployment status notes
  • Check record counts — objects with 0 records and no active flows referencing them are candidates for deletion
  • Look for objects with "Test", "Temp", "Old", or "Archive" in the name
  • Verify every active object has an identified business owner
5
Medium risk

API usage patterns (integration health)

Runaway integrations can consume your daily API limit without anyone noticing — until everything breaks. Polling integrations (checking for changes every minute instead of using streaming) are especially wasteful. An API audit tells you which integrations are healthy and which are ticking time bombs.

What to check
  • Check current API usage via Setup → Company Information → API Requests, Last 24 Hours
  • Run SOQL on ApiEvent (if Event Monitoring licensed) to see which integrations consume most calls
  • Flag any integration consuming more than 20% of your daily API limit
  • Identify polling integrations and evaluate them for Platform Events or Change Data Capture migration
  • Check Connected Apps (Setup → Connected Apps) for apps with no recent OAuth token issuance
6
Low risk (until it isn't)

Storage consumption trends

Storage overages are expensive and operational emergencies when they hit. Most orgs that hit storage limits don't realize they're approaching them until they start getting "storage limit exceeded" errors. Proactive storage audits take 20 minutes and prevent a multi-thousand dollar crisis.

What to check
  • Setup → Company Information → Data Storage and File Storage used vs. allocated
  • Run SOQL: SELECT SobjectType, COUNT(Id) FROM RecordCount GROUP BY SobjectType ORDER BY COUNT(Id) DESC
  • Flag objects growing faster than 20% quarter-over-quarter as archival candidates
  • Check ContentDocument and Attachment volume — file uploads are the most common storage explosion
  • Evaluate whether archived records (old Opportunities, closed Cases) need to remain in the org
7
Medium risk

User login patterns (license waste)

Salesforce licenses are expensive. Users who haven't logged in for 30+ days are either gone from the company (a security issue) or using Salesforce so rarely that a lighter license type would suffice. Either way, they're burning budget. License audits consistently surface 5–15% savings for mid-market orgs.

What to check
  • SOQL: SELECT Name, LastLoginDate, IsActive FROM User WHERE IsActive=true ORDER BY LastLoginDate ASC
  • Flag any active user with LastLoginDate older than 30 days — cross-reference with HR offboarding
  • Identify users whose role and tasks could be served by a lighter license type (e.g., Platform vs. Sales Cloud)
  • Look for users with active Salesforce licenses who only access one or two objects
  • Audit sandbox licenses separately — sandbox users are often left active after projects end
8
Medium risk

Sharing rule complexity

Sharing rules define which records users can see beyond their default OWD. Orgs with complex, overlapping sharing rules experience unpredictable data visibility issues and significant performance degradation when record-level operations recalculate shares. More than 50–100 active sharing rules is a warning sign.

What to check
  • Count total active sharing rules per object via Setup → Sharing Settings
  • Identify criteria-based sharing rules that reference the same field with overlapping criteria
  • Look for sharing rules created as workarounds for poor OWD design — these should be resolved at the OWD level
  • Check whether Share Groups (Apex sharing) bypass your intended security model
  • Test that users in each sharing context see records they expect (and don't see records they shouldn't)
9
Medium risk

Apex test coverage gaps

Salesforce requires 75% test coverage to deploy. Many orgs game this threshold with minimal "it runs without throwing" tests rather than meaningful assertions. Gaps in real coverage mean that breaking changes to critical business logic deploy silently — until production data is corrupted.

What to check
  • Setup → Apex Classes → filter by coverage percentage — flag any class below 75%
  • Review test classes for assertions vs. just execution — tests that never assert anything aren't real tests
  • Ensure every Trigger has an associated test class that covers all trigger events (before/after insert/update/delete)
  • Run test coverage in a sandbox before any deployment to production
  • Flag classes with 0% coverage — they can't be deployed if coverage falls below threshold
10
Medium risk (long-term)

Profile vs Permission Set architecture

Salesforce is moving away from Profile-heavy permission models toward Permission Sets and Permission Set Groups. Orgs still relying on 20+ custom Profiles carry long-term maintenance debt — every permission change requires editing multiple profiles instead of a single permission set. Salesforce announced plans to limit Profile capabilities in future releases.

What to check
  • Count total active Profiles in your org (Setup → Profiles)
  • Flag Profiles that differ from the standard in only 2–3 permissions — they're candidates for consolidation into Permission Sets
  • Identify whether your org uses Permission Set Groups (introduced for complex multi-permission scenarios)
  • Check that each active Profile follows the one-profile-per-job-function model — multiple profiles for the same role is a sign of drift
  • Review Salesforce's Permission Set migration documentation and assess your migration timeline

Get an instant org health score in 60 seconds

Not ready to run a full manual audit? OrgPilot's free health check gives you a risk score and specific findings — no Salesforce login required.

Start Free Health Check →
No Salesforce login 60-second results Free forever No credit card

How often should you audit your Salesforce org?

The honest answer: more often than you're doing it. Most admins audit annually (if at all). The orgs with the least tech debt run some version of a lightweight continuous check alongside an annual deep audit.

The continuous-vs-annual debate usually resolves to the same answer: both. A full manual audit is too slow to run monthly. But relying on an annual audit means problems compound for 11 months before anyone looks.

Minimum viable

Annual Only

One thorough audit per year. Better than nothing — but leaves 11 months of unchecked drift between each cycle.

  • Full 10-point audit each year
  • Document findings and assign remediation owners
  • Track year-over-year health trends manually
  • Best for: small, stable orgs with rare configuration changes

High-growth orgs — adding integrations, custom objects, or new business units frequently — should treat quarterly audits as the baseline, not the ceiling. Every quarter of unreviewed changes adds compounding cleanup effort to the annual audit.


Salesforce org audit questions

What should a Salesforce org audit include?
A complete Salesforce org audit should cover the 10 areas in this checklist: unused custom fields, wide permission sets, broken automation, undocumented custom objects, API usage patterns, storage consumption, user login patterns, sharing rule complexity, Apex test coverage, and Profile vs Permission Set architecture. Depending on your org's complexity, you may also want to audit Named Credentials, Connected Apps, and data quality metrics.
How long does a Salesforce org audit take?
A manual audit of a mid-sized org (200–500 users, 50+ custom objects) typically takes 8–16 hours across 2–3 days. Smaller orgs with clean governance can complete a thorough audit in 4–6 hours. If you're starting from a baseline automated health check — which takes 60 seconds — you can triage the highest-risk areas and focus manual effort where it matters most.
How often should you audit your Salesforce org?
Most orgs benefit from a full annual audit with lighter quarterly health checks. High-growth orgs — adding integrations, users, or custom development frequently — should run a quarterly full audit. The goal is catching debt before it compounds into expensive remediation projects.
What is the biggest risk in a neglected Salesforce org?
Permission creep. Over time, permission sets and profiles accumulate access that no one explicitly intended. A standard user with Modify All Data — granted for a one-week data project 18 months ago — is a standing vulnerability. Security incidents in Salesforce orgs almost always trace back to a permissions audit that never happened.
Is there a free tool to audit a Salesforce org?
OrgPilot's free health check scores your org across key risk dimensions in 60 seconds — no Salesforce login or credentials required. For a deeper analysis, you can upload your metadata package (exported via Workbench) and get AI-generated findings with severity ratings. The full AI audit is free. No credit card required.
How do I export Salesforce metadata for an audit?
Use Workbench (workbench.developerforce.com) — a free Salesforce-controlled tool. Log in with your admin credentials, go to Migration → Retrieve, select the metadata types you need (CustomField, CustomObject, Flow, PermissionSet, Profile), and download the ZIP. You can then upload that ZIP to OrgPilot for an AI-powered audit without sharing your credentials with any third party.

Get your org health score — free, instant, no login

60 seconds. No Salesforce credentials. AI-powered findings across the issues that matter most.

Start Free Health Check →
No Salesforce login 60-second results Free forever No install required