If you're a Salesforce admin, you already know the dread: a new business process gets added, a consultant "optimizes" some flows, and six months later nobody's sure what's actually running in production. This checklist gives you a systematic way to find the rot before it becomes a crisis.
This is an 18-point audit covering Security & Access, Data Model, Automation, and Performance. Work through it top to bottom. Each item tells you what to check, why it matters, and what a red flag looks like.
Or — if you'd rather skip all 18 and get the answers in 60 seconds — OrgPilot audits your metadata automatically.
Why Regular Org Audits Matter
The average Salesforce org accumulates 3–5 years of undocumented changes before anyone does a formal health check. By then you have flows that fire in wrong order, profiles with more permissions than intended, and custom objects that exist for projects that ended in 2021. A quarterly audit keeps technical debt manageable and prevents security incidents caused by permission creep.
Section 1: Security & Access Control
✅ 1. Profiles with "Modify All Data" Outside System Admins
What to check: Run a Profile report or use Setup → Profiles and filter for "Modify All Data" and "View All Data" permissions. Count how many non-System Administrator profiles have these checkboxes enabled.
Why it matters: Modify All Data bypasses all sharing rules and record-level security. One compromised user account with this permission can export or delete your entire org's data.
🚩 Red flags: More than 1–2 non-admin profiles with Modify All Data. Any integration user with Modify All Data (should use a minimal-permission Connected App user instead).
✅ 2. Password Policies & Multi-Factor Authentication (MFA)
What to check: Setup → Password Policies. Confirm minimum password length ≥ 10 characters, complexity required, and maximum login attempts set to 5 or fewer. Check Setup → Identity Verification to confirm MFA is enforced — not just "enabled."
Why it matters: Salesforce has required MFA for all users since 2022. Many orgs turned on MFA optionally but never enforced it. Unenforced MFA is the same as no MFA.
🚩 Red flags: MFA "available" but not set to Required. Password length below 10. No session timeout configured (should be 2 hours or less).
✅ 3. Inactive Users Still Licensed and Active
What to check: Reports → Manage Users → All Users report filtered by "Active = True" and "Last Login > 180 days." Cross-reference with HR if possible.
Why it matters: Former employees with active accounts are a direct security liability. Beyond security, you're paying per-seat licenses for accounts nobody uses.
🚩 Red flags: Any user who hasn't logged in for 90+ days and is still active. Service/integration accounts that are personal logins (should be dedicated system users).
✅ 4. Field-Level Security on Sensitive Objects
What to check: On objects containing PII (Contact.SSN, Account.Tax_ID, custom salary/financial fields): pull up the field definition → View Field Accessibility. Confirm that only the profiles that legitimately need the field have Read access, and only admins/specific roles have Edit access.
Why it matters: Object-level security grants access to the record; field-level security gates individual fields. If FLS is wrong, users who shouldn't see sensitive data can see it via list views, reports, and the API.
🚩 Red flags: Sensitive custom fields accessible to all profiles. Fields marked Visible but not Read-Only for roles that should only view (not edit) the data.
✅ 5. Connected Apps and OAuth Tokens
What to check: Setup → Connected Apps → Manage Connected Apps. Review which apps have oAuth tokens issued. Check "Permitted Users" — "All users may self-authorize" is dangerous for sensitive apps.
Why it matters: Connected apps with persistent OAuth tokens are long-lived attack vectors. An app approved by a user who left the company still has API access.
🚩 Red flags: Connected apps with "All users may self-authorize" + broad scopes (full, api). Tokens older than 1 year with no expiry policy. Apps from vendors you no longer use.
Section 2: Data Model Health
✅ 6. Unused Custom Fields (>80% Null)
What to check: Download your org metadata and check field_count vs. populated records. Fields where >80% of records have null values are candidates for archiving. Setup → Schema Builder gives a visual, or run SOQL: SELECT COUNT() FROM Account WHERE Custom_Field__c = null.
Why it matters: Salesforce caps custom fields per object (500 for most). Orgs that hit the limit can't add new fields needed for legitimate features. Unused fields also slow down page load times and confuse end users.
🚩 Red flags: More than 20% of custom fields are consistently null across records. Fields with names like "OLD_" or "TEMP_" or date-stamped names from old projects.
✅ 7. Validation Rules That Are Deactivated (But Not Deleted)
What to check: On each critical object (Lead, Contact, Opportunity, Account), go to Validation Rules and filter by Active = False. Review why each is deactivated.
Why it matters: A deactivated validation rule means the business logic it enforces is no longer being checked. This leads to bad data entering the org, which corrupts reports and downstream integrations.
🚩 Red flags: Validation rules deactivated >90 days with no ticket explaining why. Deactivated rules that enforce required fields (e.g., "Close Date required when Stage = Closed Won").
✅ 8. Record Types with No Records
What to check: For each object with multiple record types, run a SOQL count grouped by RecordType.Name. Identify any record types with zero records.
Why it matters: Orphaned record types add complexity to page layouts, profiles, and automation. They confuse users at record creation and create maintenance overhead.
🚩 Red flags: Record types created >1 year ago with zero records. Record types with names referencing old business lines or projects that have ended.
✅ 9. Missing or Misconfigured Lookup Relationships
What to check: On junction objects and child objects, verify that required parent lookups aren't nullable when they shouldn't be. Check for "orphan" records (child records with null parent lookups) via SOQL.
Why it matters: Orphan records break reports, triggers, and rollup summaries. A Contact with a null Account lookup won't appear in Account-centric reports or automations.
🚩 Red flags: Lookup fields set to "Don't reparent" when records should be re-parented. Significant count of child records with null parent IDs on critical objects.
Section 3: Automation & Flow
✅ 10. Flow Execution Errors in Last 30 Days
What to check: Setup → Flows → Filter by "Flow Errors." Also check App Launcher → Flow Error emails if you're subscribed. Review each fault path — does it have a Fault Connector with proper error handling, or does it silently fail?
Why it matters: A flow error means a business process didn't complete. Depending on the flow, this could mean emails not sent, records not updated, or approvals not routed.
🚩 Red flags: Any scheduled or record-triggered flow with >10 errors in 30 days. Flows with no fault paths at all — when they fail, users get a generic error with no notification to admins.
✅ 11. Duplicate Active Automations on the Same Object/Trigger
What to check: List all active automations (Flows, Process Builder, Workflow Rules, Triggers) by object. Flag any object with >1 active Before-Save flow, or with both a Process Builder and a Flow doing similar operations on the same trigger event.
Why it matters: Overlapping automations cause race conditions and unpredictable behavior. They also consume CPU time limits, causing governor limit errors during high-volume transactions.
🚩 Red flags: An object with active Process Builder AND active Flow on the same event type. Workflow rules AND flows both updating the same field. Any automation referencing another automation in a chain >3 levels deep.
✅ 12. Scheduled Flows Without Fault Paths or Notifications
What to check: Open each scheduled flow. Confirm: (1) there's a Fault element on each Action, (2) the fault path sends an email to an admin or creates a task/case, (3) the schedule start date isn't in the past with "Run Once" configured.
Why it matters: Scheduled flows run in the background. Without fault notifications, failures are invisible — business processes silently stop working and nobody knows until a user complains weeks later.
🚩 Red flags: Scheduled flows with no Fault elements at all. Flows scheduled with a start date that passed 6+ months ago (these may have stopped running).
✅ 13. Apex Triggers Without Test Coverage Above 75%
What to check: Setup → Apex Classes → Run All Tests. Review overall org coverage and per-class coverage. Focus on triggers specifically — they fire on every DML operation and have the most impact.
Why it matters: Salesforce requires 75% code coverage to deploy, but that's a floor, not a target. Triggers with 75% coverage often have edge-case bugs (null handling, bulk operations) that only surface in production.
🚩 Red flags: Any trigger with exactly 75% coverage (minimum compliance, not real quality). Test classes with @isTest but no assertions (Assert.assertEquals missing — counts as coverage without validating behavior).
✅ 14. Hard-Coded IDs in Apex, Flows, and Process Builder
What to check: Search your Apex classes and Flow variable defaults for 18-character Salesforce IDs (matching pattern 001, 003, 00Q, etc.). These are record IDs that only exist in production and will fail in sandbox.
Why it matters: Hard-coded IDs are a deployment time bomb. They work in production, fail in sandbox, and cause confusion during debugging because the error points to a non-existent record.
🚩 Red flags: Any literal 15 or 18-character ID string in Apex code. Flow decisions using literal ID values in formulas instead of querying by name/external ID.
Section 4: Performance & Limits
✅ 15. SOQL Queries Without Selective Filters (Full Table Scans)
What to check: Review Apex code for SOQL queries on large objects (Contact, Lead, Opportunity) that don't filter on indexed fields. Standard indexed fields: Id, Name, CreatedDate, LastModifiedDate, and any field with an External ID.
Why it matters: Non-selective queries on large objects hit governor limits under load. Salesforce will force-fail queries that would scan >1M records without a selective filter, causing user-facing errors.
🚩 Red flags: SOQL queries like SELECT Id FROM Contact WHERE Custom_Text__c = :value on objects with >100K records where Custom_Text__c isn't indexed. Queries inside loops (nested SOQL).
✅ 16. Storage Usage Above 80%
What to check: Setup → Storage Usage. Review both Data Storage and File Storage separately. Identify the top consumers — usually Chatter files, email attachments, or Salesforce-created ContentDocumentLink records.
Why it matters: When storage is full, DML operations fail. Users can't create records. Integrations start throwing errors. This is one of the few Salesforce limits that causes a hard stop for all users simultaneously.
🚩 Red flags: Data or File storage above 80%. ContentVersion/ContentDocument tables consuming disproportionate storage (common with email-to-Salesforce or Document uploads). No process for archiving old files.
✅ 17. API Usage Approaching Daily Limits
What to check: Setup → System Overview → API Requests, Last 24 Hours. Compare against your org's daily limit (varies by edition: 5K for Developer, 15K for Professional, 100K+ for Enterprise). Identify the top consumers via API Usage reports.
Why it matters: Hitting the API limit blocks all external integrations (Zapier, middleware, third-party apps) for the rest of the day. A misconfigured integration polling every second can consume your daily limit by noon.
🚩 Red flags: Daily API usage regularly above 70% of limit. A single connected app consuming >30% of daily API calls. No monitoring alerts configured for API limit thresholds.
✅ 18. Report and Dashboard Performance
What to check: Identify reports that take >30 seconds to run. These are candidates for optimization. Check if reports are using cross-filters (expensive), joining multiple objects without filters, or running on objects with millions of records without date range limits.
Why it matters: Slow reports frustrate sales reps and managers. They'll stop using Salesforce and maintain their own spreadsheets, defeating the purpose of the CRM.
🚩 Red flags: Reports with no date filter on objects with >500K records. Dashboards that auto-refresh every 5 minutes running 10+ complex reports. Reports using "All Time" date range on historical objects.
What to Do With Your Findings
After working through the checklist, you'll likely have a mix of quick wins (deactivate unused record types, freeze inactive users) and longer-term projects (untangle overlapping automations, improve test coverage). Prioritize by risk: security issues first, governor limits second, everything else third.
For the security items especially — don't defer. Permission creep and inactive users are the most common vectors in Salesforce data incidents.
Don't want to do this manually?
OrgPilot automates the entire audit. Upload your org's metadata export and get a report covering all 18 categories above — plus AI-generated fix recommendations — in about 60 seconds.
Audit My Org Free →No login required. Results in 60 seconds.
Related: Need to export your metadata first? See our guide: How to Export Salesforce Metadata for an Org Audit (Step-by-Step)
Related: Focused on security? Use the dedicated Salesforce Security Review Checklist for a deep-dive into permissions, FLS, sharing rules, and API access controls.