A Salesforce audit is the clearest way to understand whether your org is still under control — or whether it has been quietly accumulating technical risks, governance failures, and operational blind spots. When reports stop adding up, automations break existing flows, and no one can explain a change made in production, the problem is almost always a lack of visibility into the instance.
A Salesforce org rarely fails all at once. It loses predictability gradually: the board’s report starts moving away from the sales team’s figures, a new automation interferes with an older flow, a deployment that used to take two days now takes two weeks, and answers become increasingly dependent on specific individuals. In this article, you will find 10 practical questions to help you identify whether your instance needs a Salesforce audit before your next critical project goes live.
What is a Salesforce audit?
A Salesforce audit is a structured analysis of the org — that is, the company’s Salesforce instance — covering everything it has accumulated over time: configuration, code, data, permissions, integrations, automations, and business rules. The goal is to restore visibility across the environment to identify risks, technical debt, performance bottlenecks, security vulnerabilities, and anything that could compromise the platform’s evolution.
This kind of diagnostic matters because many organisations continue running Salesforce on assumptions. A field was created for a process that no longer exists. An automation was kept running long after it lost its purpose. An integration depends on a vendor that has since changed its authentication model. A permission rule was broadened to resolve an urgent situation and was never reviewed again.
Over time, this accumulation of small decisions produces an org that is difficult to explain. An instance where the business cannot explain is difficult to govern, scale, or prepare for new projects.
A Salesforce audit goes beyond Health Check
Before moving on to the questions, it is worth clarifying the scope. A Salesforce audit goes well beyond the platform’s native Health Check.
According to Salesforce’s official Health Check documentation, the feature compares the org’s security settings against Salesforce’s recommended baseline. This analysis generates a score and helps administrators identify security risks.
That feature is useful, but insufficient for a complete picture of the org. Health Check covers an important security dimension, but it cannot answer questions about technical debt, user adoption, duplicate automations, fragile integrations, change traceability, actual field usage, or how close the org is to platform limits.
This is why a Salesforce audit must go beyond a security score. It needs to connect the technical assessment with operational impact and business priority. The question is not simply “what is out of standard?” — it is “what could generate risk, delays, rework, or loss of control for the business?”
10 triage questions for your Salesforce org
The questions below work as a quick triage. If three or more answers are “I don’t know,” the org may already be running on assumptions. At that point, a Salesforce audit is no longer just a preventive measure — it becomes an essential step towards regaining control.
1. Do you know how many automations run on your core objects?
Orgs with a long history tend to accumulate layers: legacy Workflow Rules, inherited Process Builders, newer Flows, and Apex triggers that were not always documented. If the picture is unclear for objects such as Lead, Opportunity, Case, and Account, there is a real risk of automation conflicts.
This kind of problem does not always surface as a clear error. It often appears as erratic behaviour: a field filled in twice, a stage changed without explanation, an email sent at the wrong time, or a flow breaking after what seemed like an easy change.
2. Is there someone who can explain every active integration?
Integrations are where risk moves out of Salesforce and into the extended operation. ERPs, customer service platforms, marketing tools, financial systems, billing solutions, and legacy applications may all depend on the org to function correctly.
Without an inventory that documents ownership, purpose, volume, authentication method, and failure behaviour, incident response becomes an investigation. And investigations during business hours are costly — particularly when they affect customer service, sales, or billing.
3. Does any integration or package still rely on an older API version?
This is a technical issue with direct corporate impact. According to Salesforce’s official documentation on the retirement of Platform API Versions 21.0 to 30.0, these versions were deprecated in Summer ’22 and withdrawn in Summer ’25. Calls to retired versions may return errors such as 410 in REST, 500 in SOAP, and 400 in Bulk API.
Salesforce has also announced that the SOAP API login() call in versions 31.0 to 64.0 will be withdrawn in Summer ’27 for external client applications used for authentication.
Integrations that rely on these resources may continue to work normally until the release reaches the org — and then stop without any operational warning. Those without a proper inventory discover the risk in the worst possible way: in production.
4. How much of your Apex code has meaningful test coverage?
Minimum coverage passes a deployment, but it does not guarantee correct behaviour. Tests that merely instantiate records without validating outcomes create a false sense of security.
If the team avoids touching certain classes because “that bit is sensitive,” the problem is not just legacy code — it is an area of the org that has lost maintainability. In a Salesforce audit, Apex analysis needs to look beyond coverage percentage to assess quality, intent, and the code’s ability to protect the platform as it evolves.
5. Do the board’s reports reconcile with the operational team’s reports?
A difference in figures is almost never just a reporting problem. It typically originates in a duplicated field, an inconsistent validation rule, a record created by an integration without proper standardisation, or teams measuring different pipeline stages under the same name.
Until the inconsistency is resolved at the source, every meeting becomes a negotiation over which spreadsheet is correct. This is a clear signal that the Salesforce instance has stopped being the single source of truth and has started coexisting with parallel interpretations.
6. Do you know which custom fields and objects are no longer in use?
An unused field is not neutral. It appears in page layouts, shows up in reports, confuses users, extends mobile screens, and adds weight to migrations and integrations. Custom objects without a clear purpose also raise complexity and make the org harder to maintain.
A Salesforce audit should map the actual usage of these items to identify what can be deactivated, consolidated, or retained. This is often one of the quickest wins from a well-conducted diagnostic.
7. Who has access to what, and why?
Inherited profiles, accumulated permission sets, access granted to resolve urgent situations, and active licences assigned to users who have since left the business form a silent risk. Taken together, they affect security, GDPR compliance, and licence costs.
If the question “why does this profile see this data?” has no documented answer, access governance is unofficial. Inside environments handling sensitive data, informal permission management can quickly become a technical, legal, and operational problem.
8. Is your org comfortably within the platform’s limits?
Governor limits, data volume, API quotas, field counts per object, and storage limits rarely cause concern — until they become a blocker. The problem is that when an org is already operating close to its ceiling, any new project has less room to grow.
An audit helps identify these constraints before they compromise a deployment, an integration, or a major expansion. Rather than discovering a limitation mid-project, the business can plan corrections and prioritise preventive action.
9. Can you trace who changed what, when, and why?
Changes made directly in production — without records, without a test environment, and without documentation — are among the most common causes of unexplained behaviour. Traceability matters for technical diagnosis, security, and compliance.
Without a reliable change history, every incident starts from scratch. With proper traceability, the team can identify the cause, responsible party, impact, and path to resolution far more quickly.
10. Before extending AI across the org, do you know where the data comes from?
AI agents and intelligent automations inherit both the quality and the permissions of the underlying Salesforce data. Duplicate records, unstandardised fields, and poorly defined access controls do not disappear when an AI layer is introduced. On the contrary, they scale and can surface in customer-facing responses, internal recommendations, or automated workflows.
This has become one of the highest-priority questions in recent months. The cost of getting it wrong is no longer confined to internal operations. In projects involving Agentforce, AI applied to CRM, and advanced automation, a Salesforce audit may be a prerequisite for moving forward safely.
How to interpret your answers
A practical way to turn this triage into a decision is to count the number of negative or uncertain answers.
Zero or one negative answer: The org is under control. It is worth conducting periodic reviews — annually or every six months — and documenting the inventory before it is lost due to team or supplier changes.
Two to four negative answers: Technical debt is already having an operational effect, most likely felt as slower delivery and increased rework. An audit at this stage is manageable: it fits into a normal cycle, with a prioritised backlog and phased remediation.
Five or more negative answers: The org is being run on assumptions. In this scenario, any new project, AI expansion, significant integration, or migration carries a high risk of overrunning — because estimates are being made against a system that no one has fully mapped. An audit becomes a prerequisite, not an improvement.
There are also specific triggers that accelerate the decision, regardless of the count: a change in implementation partner, a merger or acquisition, entering a new market with different regulatory requirements, a shift in the commercial model, or plans to scale AI agents across the CRM. In any of these situations, diagnosing first is cheaper than correcting afterwards.
Salesforce audit: diagnosis first, backlog second
The most common mistake is not failing to audit at all. It is auditing, then turning the output into an extensive report—hundreds of findings that no one has the capacity to act on.
A useful Salesforce audit needs to deliver three things. First, a map of what exists: code, configuration, automations, integrations, permissions, actual usage, and risk areas. Second, prioritisation by business impact — an automation generating incorrect revenue figures takes precedence over an elegant refactor that changes nothing immediately. Third, a remediation plan with an owner, a sequence, and acceptance criteria.
That is precisely what OrgAudit 360 addresses. The platform performs a complete scan of the Salesforce environment in 30 to 45 minutes, depending on the complexity of the instance, assessing it end-to-end across security, performance, scalability, compliance, and efficiency.
The automated scan addresses what manual analysis does poorly: covering the entire org without relying on small samples or the team’s memory. The consultative layer resolves what no tool can decide on its own: what enters the next cycle, what should be treated as an important risk, and what can wait.
Where Biz2People fits into this process
Biz2People specialises in Salesforce consultancy, technical audits, governance, and environment optimisation. This combination matters because an audit should not stop with a standalone diagnosis. It needs to become an actionable plan — with clear priorities, governance, and the technical capacity to execute the remediation.
Within the context of OrgAudit 360, the company combines automation, artificial intelligence, and specialist consultancy to support organisations seeking to regain visibility across their orgs. The goal is not simply to identify problems, but to help understand the impact of each finding and build an evolution backlog that is coherent with the business.
This perspective is particularly relevant for organisations that use Salesforce as the foundation for relationship management, sales, customer service, operations, or decision-making. When the org underpins critical processes, every blind spot can lead to delays, rework, security risks, or a loss of confidence in the data.
A healthy Salesforce instance is not one with minimal customisation. It is one that the business can explain, govern, and evolve with confidence.
Conclusion
Auditing is not an act of distrust towards what has been built. It is about regaining control over what the business depends on every day. When a company cannot explain its automations, integrations, permissions, limits, reports, and data, every new project carries invisible risk.
A Salesforce audit turns assumptions into diagnoses, and diagnoses into priorities. It shows where the risks are, which issues affect the business, and which fixes need to be added to the backlog first. In a Salesforce landscape that is increasingly connected to AI, automation, data, and customer experience, this perceptibility is no longer a technical detail — it is the basis for sustainable growth.
Run these ten questions with your IT team and the person responsible for Salesforce in the same room. Count how many cannot be answered objectively. That number alone will help you gauge the immediacy, even before a full diagnostic begins.
Start your free audit at orgaudit.ai or speak to the Biz2People team
🔗 Blog – 🔗 Linkedin – 🔗 Instagram
➡ Share this with whoever makes technology decisions in your organisation
FAQ — Frequently asked questions about Salesforce audits
What is a Salesforce audit?
A Salesforce audit is a structured mapping of the org’s code, configuration, automations, integrations, permissions, and actual usage, designed to identify risks, technical debt, and opportunities for improvement.
Is a Salesforce audit the same as a Health Check?
No. Health Check evaluates security configurations against a baseline. A Salesforce audit covers a broader scope, including technical debt, integrations, automations, user adoption, change traceability, and platform limits.
How often should a Salesforce org be audited?
For stable operations, an annual review may be sufficient. Orgs with frequent changes, multiple integrations, or an active development team may benefit from reviewing every six months.
Do I need to audit before deploying AI in Salesforce?
In practice, yes. AI agents use the data and permissions already present in the org. If there is duplication, poorly defined access, or inconsistent data, those problems will scale.
How long does a diagnostic with OrgAudit 360 take?
The automated scan takes between 30 and 45 minutes, depending on the instance’s complexity. The consultative phase — prioritisation, curation, and backlog planning — varies according to scope and the integrations being analysed.
What are the signs of technical debt in Salesforce?
Divergent reports, conflicting automations, integrations without a clear owner, slow deployments, unused fields, poor change traceability, and over-reliance on specific individuals are all common indicators.
What does OrgAudit 360 analyse?
OrgAudit 360 analyses code, configuration, security, performance, compliance, licensing costs, change traceability, permissions, and technical risks across the Salesforce instance, supported by AI and specialist consultancy.
