5 Signs Your Salesforce Org Needs an Audit

The symptom

Sales reps complain that the Opportunities list view takes 10+ seconds. A manager's pipeline dashboard spins for 30 seconds before rendering. Someone runs a report and hits the "Your report took too long" timeout error. These aren't one-off browser hiccups — they happen consistently.

Why it matters

Slow Salesforce is a data quality and architecture problem masquerading as a UX complaint. The most common culprits: non-selective SOQL queries scanning millions of records without indexed filters, report cross-filters running against objects with no date range constraints, and page layouts loading dozens of related lists that trigger separate queries on every open.

When Salesforce decides a query would take too long, it doesn't slow down gracefully — it hard-fails with a governor limit error. At high record volumes, what's "a bit slow today" becomes "completely broken next month."

Performance problems also indicate technical debt from multiple configuration eras: an Apex trigger added in 2019, a Process Builder added in 2021, and a Flow added last year — all firing on the same record save event and competing for CPU time.

What OrgPilot finds

OrgPilot flags Apex classes with SOQL queries inside loops (the classic N+1 problem), triggers without bulkification patterns, and automation conflicts where multiple active tools fire on the same object/event combination. It surfaces these in the Performance section of your audit report with severity ratings and specific fix recommendations.

The symptom

A new admin joins and opens the Account object in Schema Builder. They're greeted by 180 custom fields, at least 40 of which have names like Old_Revenue__c, Q2_2022_Target__c, or TEMP_Migration_Flag__c. Nobody knows what half of them are for. Page layouts are cluttered. Users ignore most fields. Data quality is low because nobody knows which fields actually matter.

Why it matters

Salesforce caps custom fields per object — 500 for Enterprise and above, fewer for lower editions. Orgs that accumulate unused fields hit this limit at the worst possible time: when a new feature actually needs a field. You can't add it. The project stalls while someone cleans up the mess.

Beyond limits, field bloat degrades your data model's legibility. If your team can't easily answer "what does this field store and who uses it," you have a documentation and governance problem. That problem gets worse every month as more fields are added without a deprecation process.

Security is also affected. If you don't know what a field contains, you can't properly configure Field-Level Security for it. Sensitive data ends up accessible to profiles that shouldn't see it.

What OrgPilot finds

OrgPilot analyzes your metadata export for custom field counts by object and flags objects approaching Salesforce's field limits. It identifies fields with naming patterns that suggest legacy or temporary use (OLD_, TEMP_, date-stamped names). The Data Model section of your audit shows which objects have the most field clutter so you know where to start the cleanup.

The symptom

Six months ago, a consultant ran a security assessment and produced a 12-page report. Three items were marked "Critical." Two were marked "High." You fixed the critical ones (or thought you did). The high-severity items went into a backlog ticket that's been sitting at priority 3 ever since. Nobody remembers exactly what was in the report.

Alternatively: your company just hit SOC 2 or ISO 27001 scope, and the auditors are asking about Salesforce access controls. You realize you don't have clean answers to questions about who has Modify All Data or how many inactive users still have active licenses.

Why it matters

Salesforce permission problems are sticky. Permission creep happens gradually — a user needed elevated access for a project, the project ended, the access was never removed. Multiply that across 3 years and 50 users and you have a significant blast radius if any account is compromised.

The most dangerous permissions in Salesforce aren't the ones you deliberately grant — they're the ones you forgot about. Profiles with "Modify All Data" inherited from a template. Integration users with full API access that should have been scoped down. Connected apps from vendors you stopped using that still have valid OAuth tokens.

Compliance gaps don't just create audit findings. They create liability. A Salesforce account with broad permissions that gets phished is a GDPR, CCPA, or HIPAA incident depending on what data your org holds.

What OrgPilot finds

The Security & Access section of every OrgPilot audit checks for profiles with Modify All Data outside System Administrators, MFA enforcement status, inactive users still holding active licenses, and field-level security misconfigurations on sensitive objects. These are the exact items that come up in compliance reviews — surfaced automatically from your metadata without requiring manual Setup navigation.

The symptom

A record is updated and three different things happen — some expected, some not. When you try to trace why, you find an active Workflow Rule, a Process Builder, and a Flow all configured on the same object with overlapping trigger conditions. An Apex trigger also fires on every save. Nobody who's currently on the team built all of these — they accumulated over 5+ years of admins, consultants, and projects.

Debugging takes hours because you can't easily see the execution order. Users report intermittent errors ("sometimes the email sends, sometimes it doesn't") that you can't reliably reproduce.

Why it matters

Salesforce has a documented automation execution order, but it's complex: before-save flows, then Apex triggers, then process builders, then after-save flows, then workflow rules. When multiple automations fire on the same event, they can conflict — one updates a field, another reads the pre-update value and acts on stale data, a third fires a callout that's already been made.

Salesforce has been deprecating Workflow Rules and Process Builder since 2023. Orgs that haven't migrated these to Flow are running on tools that no longer receive bug fixes and will eventually stop working. The migration pressure makes the untangling problem urgent, not optional.

Governor limits make it worse at scale. Each automation consumes CPU time and SOQL query limits. An org with overlapping automations that works fine at 100 records/day can hit governor limit errors when volume spikes.

What OrgPilot finds

OrgPilot parses your Flow, WorkflowRule, and Apex metadata and maps automation by object and trigger event. The Automation section flags objects with multiple active automations on the same trigger, identifies deprecated Workflow Rules and Process Builders that need migration, and surfaces flows missing fault paths — the most common cause of silent automation failures.

The symptom

Your first admin left in 2022. A consultant filled the gap for a year. Your current admin inherited an org they didn't build. Nobody fully documented what was done before them. The current admin is competent, but spends a disproportionate amount of time asking "why does this work this way?" and working around legacy decisions instead of building new things.

There's a general feeling that "we should do a cleanup" but it never happens because the cleanup seems impossibly large and nobody knows where to start.

Why it matters

Admin turnover is the primary driver of Salesforce technical debt. Each admin brings their preferred configuration patterns. Consultants add functionality quickly without long-term ownership. The result is a layered org where the current state reflects every decision ever made — including the bad ones.

Technical debt in Salesforce compounds. An unused field doesn't get cleaned up, so it stays in page layouts, which stay in profiles, which stay in permission sets. A deprecated automation doesn't get removed, so new automations get built around it. By year 5, the org is slower, harder to change, and more fragile than it needs to be — not because anyone made a catastrophic mistake, but because small decisions accumulated without a cleanup process.

The fix isn't a massive 3-month cleanup project. It's a systematic audit that tells you what's actually in your org, ranked by impact, so you can make incremental progress without guessing.

What OrgPilot finds

An OrgPilot audit gives you a full inventory of your org's metadata — custom objects, fields, flows, triggers, profiles, permission sets — with a health score (0–100) and prioritized findings. It's the baseline you need to start a cleanup, even if you can only fix three things this sprint. New admins use it on day one to understand what they've inherited. See the complete 18-point audit checklist for the full set of items OrgPilot checks.