Guide to Salesforce Health Check In 2026

Configuration drift is an inevitable phenomenon in the enterprise setting as an organization grows. The incremental changes are made over time by various administrators, developers, and external consultants, all of them well intended but seldom in sync with a single architectural approach.

Over time, the Salesforce environment turns into a quilt of setups, overlapping automations, conflicting permission structures, and old metadata. This accruing drift destroys predictability of the system, augments operational risk, and makes future upgrades more costly. An organized Salesforce Health Check re-architecturizes the org to bring it back to architectural discipline and bring back clarity, control, and alignment to business objectives.

Unmanaged Salesforce orgs tend to accrue shadow permissions, unnoticed or lost access privileges that are no longer in line with corporate policy or regulatory standards. These are legacy accounts that have extensive CRUD privileges, idle users with high-level access. They are also session settings so lenient that they do not meet the current compliance requirements of ISO 27001, SOC 2, HIPAA, or GDPR.

A Salesforce Health Check is a systematic review of:

• Least-privilege violation profiles and permission sets.
• OWD and sharing models causing unintended data exposure.
• Resilience to credential and session hijacking policies, login and session policies.
• External access administration via Connected Apps and API tokens.

It can be measured by comparing variations to the Salesforce Security Baseline, which creates a verifiable score of security risk. It allows internal governance teams and external auditors to confirm that your Salesforce footprint is in compliance with the required compliance models.

Technical debt in Salesforce grows silently but significantly. It appears in forms such as:

• Apex and formula fields that contain hard coded IDs.
• Unpredictable triggers or flows that are not bulkified and scale unpredictably.
• Unutilized, dormant, or redundant process automation logic.
• Managed packages that are installed but not used and that complicate matters.
• Classes that are based on old versions of the API.

This debt gradually turns into an impediment to innovation. What could be easy updates, for example implementing a small improvement, becomes risky change management. Regression failures increase, deployments become unpredictable, and sandbox to production behavior becomes inconsistent.

A Salesforce Health Check identifies these architectural liabilities. It allows organizations to regain development pace and decrease regression risk. It also helps create a Salesforce environment that enables long-term scalability.

Performance degradation is often initiated by friction, including:

• Lightning record pages taking too long to load.
• Query performance decreasing with increasing data volumes.
• Intricate automation routes causing record saves to be slow.
• Row locking or data skew on high-volume objects.
• List views failing because of a large number of records.

Large data volumes, poor indexing techniques, and redundant layers of automation create a slow and frustrating user experience. These inefficiencies reduce productivity and destroy user trust, often compelling teams to return to spreadsheets.

A Salesforce Health Check will find these systemic inefficiencies, rationalize data and metadata structure, and provide the platform with sub-second responsive interactions.

A majority of Salesforce customers end up paying more than they realize. Health Checks reveal:

• Premium users with only basic features in use.
• Premium platform extensions (Service Cloud, CPQ, Knowledge) assigned to dormant users.
• Unmanaged feature activations that become shelfware.
• Licenses for duplicate or redundant features.

A Salesforce Health Check identifies which users are downgradeable. It reveals which licenses can be reclaimed and where orgs can be moved to lower priced license levels. This optimization creates short and quantifiable cost savings.

This tool can be accessed by going to Setup > Security > Health Check and assesses your org against the Salesforce Security Baseline and scores it out of 0 to 100.

It analyzes:

• Password complexity
• Session controls and session timeout
• CSP (Content Security Policy) security
• Clickjack and browser security
• Certificate expiration
• Trusted IP ranges

In addition to the Salesforce standards, organizations can add their own XML security baselines to test their compliance with industry specific standards such as FINRA, HIPAA, or company policies. This renders the Health Check as one of the cornerstone tools of enterprise audit preparation.

The Optimizer offers the static analysis of your org in 50+ dimensions such as:

• Unused custom fields
• Excessive validation rules
• Excessively elaborate Lightning pages
• Stale report folders
• Redundant record types
• Inactive automation
• Page complexity metrics
• Flow usage and quality of configuration

Its output PDF provides a prioritized list of improvement actions which are technically justified. Thus, it is a necessary tool in metadata cleanup and performance improvement.

The Developer Console is still one of the most useful tools of deep diagnostic work. The administrators and developers have the ability to:

• Run real time SOQL queries
• Determine unselective queries that lead to performance degradations
• Check CPU time, heap size, and DML or SOQL utilization
• Identify Apex trigger recursion problems
• Measure governor limit runtime consumption
• Analyze locking conflicts and parallel transactions

This instrument aids in technical analysis on a forensic level, which is vital in the determination of performance and scalability bottlenecks.

To support technical scrutiny on enterprise grade, the following types of code are evaluated using the help of static code analysis tools:

• SOQL injection risks
• Field level security (FLS) breaches within Apex
• LWC vulnerability to cross site scripting (XSS)
• Hard coded logic and anti patterns
• Complexity rating and maintainability
• Deprecated API patterns

These tools expose engineering and security problems which the native Salesforce tools do not identify and are therefore essential to high maturity orgs.

This fault is manifested in cases where synchronous Apex processing surpasses Salesforce rigid CPU limits.

Root causes include:

• Nested loops
• Recursive triggers
• Excessive automation discharge
• Non selective SOQL queries
• Large in memory collections

This symptom is an indicator of high automation and inefficiency of codes.

Errors of UNABLE to LOCK ROW are induced by having two or more processes trying to update a parent record at the same time.

Common triggers include:

• Data skew
• Lack of ownership distribution of records
• UI transactions in conflict with batch jobs
• Simultaneously firing flows and triggers

This is indicative of more serious problems in data modeling and automation sequencing.

Reports which keep on timing out point to more fundamental architectural issues like:

• Fields that are not indexed in filters
• Unnecessarily huge queries of datasets
• Poor data architecture
• Fragmented ownership of records
• Missing custom indexes

Slowness in reporting is commonly directly related to defects in data structure rather than user error.

Repeated deployment failures are an indication of:

• Improperly controlled metadata dependencies
• Unpredictable behavior of automation
• Inconsistent API versions
• Unreliable test classes
• Namespace conflicts
• Outdated technical elements

This implies that there is no metadata governance.

The digital clutter is built up by:

• Unassigned profiles
• Inactive workflow rules
• Zero records of custom objects
• Neglected approval procedures
• Outdated designs and validation rules that were not used

This bloat slows down the productivity of the administration, slows down deployments, and disorientates users.

It's time to do a thorough inspection of your profile and permission set architecture. The modern way of doing things is to stick with a "Minimum Access" profile model. That means you set up a base profile with the bare minimum of permissions and then add extra access via permission sets and permission set groups that are modular and easy to manage.

• Audit Time: Run a SOQL query on the PermissionSetAssignment object to find all users who have got handed high privs like being able to modify all data or view all data. Those kind of permissions should only be granted by super careful System Administrators who really need them.

Take a close look at your Organization-Wide Defaults (OWD) - they are the building blocks of your record sharing model.

• Security 101: for core objects like Account and Contact, you should be setting the external OWD to "Private". This means people can't just have access - you need to set it up explicitly via sharing rules or other means. It’s a more secure way to do things.
• Risk Alert: Review any custom objects configured with “Public Read/Write” OWD settings, as that level of access is typically too permissive. And while you're at it check out how many criteria based sharing rules you have - ideally it should be no more than 50% of the objects, otherwise it can start to slow things down when you try and save records because of the Group Membership Locking process.

Go to Session Settings in Setup and take a look at your security policies. Check if sessions are locked down to the IP address where the session originated, that's a defence against session hijacking. Also, make sure Force logout on session timeout is enabled so that sessions don't just get left open indefinitely.

Execute all local Apex tests from the test runner.

• Code Audit: Identify all Apex classes with API versions older than three years (finding a class with API v45.0 in 2025). Older API versions may lack newer platform features, performance optimizations or critical security patches.
• Flag for Refactoring: Search your codebase for test classes using the SeeAllData = true annotation. This violates the best data isolation practice for testing and produces unreliable/unpredictable test results.

Use tools to find and catalog unused or redundant metadata components.

• Unused Custom Fields: All custom fields that have not been added to any page layout and that are not referenced in any Apex code, flows, or formulas are dead weight and should be deprecated and possibly deleted.
• Stale Reports & Dashboards: Do a SOQL query against Report and Dashboard objects for items where LastRunDate is more than 12 months ago. Archiving these assets should declutter the analytics folder structure and improve navigation for users.

Check all entries in Connected Apps and Remote Site Settings. Revoke all OAuth tokens associated with unused or decommissioned applications immediately. And for all active integrations, use dedicated Integration User licenses with very restricted permission sets instead of full System Administrator profiles, which pose a serious security risk.

Do detailed analysis by querying the User object for the LastLoginDate field. All users who haven't logged in for more than 60 days should be flagged. These users should be deactivated or downgraded to a less expensive license type like "Chatter Free" or "Identity" if all they want is read-only access to documents or communities.

Conduct a specific audit of assignments for expensive/specialized feature licenses like Service Cloud User, Sales Cloud User, or Marketing User. Verify that the users assigned to these licenses are actually using the appropriate features, such as the Service Console or marketing campaign tools. If they are not, delete their permission set from their user record so it can be freed up for other employees who need it.

Navigate to the Company Information page in Setup and compare your "Used Licenses" count for each license type against the quantities specified in your Salesforce contract. If your high-cost "Full CRM" licenses are consistently getting only 60% utilization, you might consider swapping some of them for less expensive "Platform Starter" licenses. Such a strategy works well for users that require access to only certain custom objects and a subset of standard CRM objects.

Each finding should be categorized into a standardized severity and impact matrix.

• Critical Priority: This category includes all major security vulnerabilities (e.g. Health Check score below 50), consistent Governor Limit exceptions that cause service disruptions, and identified data loss risks. These items need an immediate fix.
• High Priority: Issues causing severe performance degradation / major technical debt / clear examples of license wastage fall under this category. Such things should be covered in the next planned development sprint.
• Medium Priority: That means there are UI/UX-related user experience inconsistencies and minor unused metadata instances. These can go into the long-term technical backlog.

For each identified fix, create detailed user stories or tasks in your Application Lifecycle Management (ALM) tool, such as Jira or Azure DevOps Center.

• Standard Format: A good story should have a format, for example: As an Administrator, I need to implement a new workflow rule to streamline the lead assignment process, ensuring a smooth workflow and reducing the risk of CPU timeout exceptions during peak lead generation periods.

Create a simple, high-level Salesforce Dashboard or a slide deck to summarize findings for stakeholders. This summary should include:

• Current Security Score versus the target goal.
• Total number of critical/high-priority issues identified.
• Estimated annual ROI on license reclamation/optimization.

Automated regression testing is a requirement in those environments that experience frequent deployments or where more than one team is updating Salesforce simultaneously. Manual testing is not able to keep up with the change rate, and untested releases have operational risk.

With the help of such tools as Selenium, Provar, or Autify, organizations are able to:

• Automate critical flow test suites (Lead assignment, Case escalation, Opportunity stage progression).
• Check business logic every time business logic changes.
• Identify the regressions of automation when there are changes in the Flow or Apex.
• Make Lightning UI components work across browsers and devices.
• Decrease the time of testing by days to hours, and accelerate deployment.

Conceptually, automated testing acts as the immune system of your Salesforce org. When something changes that threatens functionality, your tests detect and isolate the issue before it impacts users.

The current Salesforce ecosystems deploy CI/CD pipelines (GitHub Actions, Azure DevOps, GitLab, Copado, Gearset) to instil discipline over deployments. CI/CD converts Salesforce development from a manual and unpredictable process into a controlled engineering process.

With the help of the combination of static code analysis and automated quality gates in CI/CD:

• PMD or CodeScan is capable of preventing potentially dangerous Apex patterns in production.
• Metadata validation makes sure that there are no missing dependencies and incompatible versions of the API.
• Artifacts of deployment are completely traceable and can be rolled back and audited.
• The difference between sandbox and production is reduced with metadata version control.

Basically, CI/CD establishes a repeatable trust pipeline where all changes in deployment are verified, compliant, and safe.

Even with good governance, Salesforce orgs accumulate clutter over time. Deep clean sprints are quarterly events that enable organizations to get rid of the inefficiencies that have built up over time and reestablish architectural clarity.

In such sprints, the teams concentrate on:

• Eliminating custom fields that are not in use that inflate page layouts and metadata.
• Storing past activities, occurrences, records, and past items that lead to LDV problems.
• Refactoring unoptimized Flows or inefficient Apex classes.
• Deactivating outdated Process Builders and Workflow Rules.
• Unifying the duplicate page layout to make the user experience easier.
• Eliminating non active permission sets or non active approval processes.

Such sprints minimize system entropy. In theory, they are preventive maintenance, ensuring the system is lean, predictable, and scalable in the future.

A formal Salesforce Center of Excellence (CoE) or governance board anchors Salesforce strategy around standards, quality, and shared accountability. This team dictates architectural choices, making sure that new functionality and improvements do not cause a technical debt reprise or unbalanced settings.

The CoE typically oversees:

• Standards of data architecture (naming conventions, field design, lookup vs master detail).
• Flow design patterns and Apex and Flow boundaries are all under the control of automation.
• Security checks which implement least privilege access.
• Release management which establishes the movement of changes through sandboxes.
• Documentation standards which make all features traceable.
• Integration patterns such as when to use APIs vs Platform Events vs Mulesoft.

Fundamentally, a governance board establishes Salesforce as a strategic platform, not just an operational tool, ensuring changes support long-term organizational objectives.

The periodical health examination will keep your org within governor limits and architectural guardrails. This prevents:

• Unexpected CPU spikes.
• Flow or trigger recursion loops.
• Query timeouts.
• Record locking failures.
• Data skew incidents.

Operational resilience implies that the system will act in a predictable way at peak business times so that the system has 99.9 percent uptime and continuous sales, service, and operational processes.

Rather than scurrying to get ready to undergo audits such as ISO 27001, SOC 2, HIPAA, or internal IT governance audits, an organization that is well maintained is always audit ready.

Benefits include:

• Stable security baseline scores.
• Formal access and privilege policies.
• Managed change management artifacts.
• Current adherence to MFA, encryption, and IP restrictions.
• Proper records of management activities.

Conceptually, uninterrupted preparedness implies that Salesforce is not a compliance burden anymore, but rather a compliance asset.

Teams are sluggish with high technical debt. A well managed and clean org allows:

• Faster project delivery.
• More reliable deployments.
• Lower regression risk.
• Increased confidence of the developer.
• More rapid adoption of features (Flows, Einstein AI, Omni Channel, etc.).

Health checks often uncover significant cost savings by optimizing:

• Unused feature licenses.
• Unutilized or underutilized CRM licenses.
• Overprovisioned add ons.
• Poor use of contracts.
• Unnecessary third party tools which can be substituted with native Salesforce features.