Salesforce Optimizer used to give admins a fast way to spot visible issues in an org. It surfaced configuration findings, feature use, limits, and cleanup opportunities. That made it useful as a first pass, especially when teams needed a simple list of items to review. The problem was easy to miss: a diagnostic snapshot can only report what it was built to measure. A good-looking result never proved the whole Salesforce environment was healthy.
That limitation matters even more now. Salesforce has retired the Optimizer app, so teams that still have old reports or internal checklists based on it need a broader way to judge Salesforce org health. Old Optimizer reports still answer a narrow question about what the tool flagged. The useful question now is, “What evidence do we have that this org is secure, maintainable, fast under real load, trusted by users, and safe to change?”
This guide explains the gaps the old tool never closed. It also shows how to build a current org review using native Salesforce tools, code analysis, operational evidence, and business context. The goal is to find risk before a release, migration, audit, or incident forces the issue.
TL;DR
Salesforce Optimizer was useful for finding visible configuration issues, but it was never a full diagnosis of Salesforce org health. Salesforce has now retired the app, which makes its limits more important for teams that still rely on old reports or inherited admin routines. The official Salesforce Optimizer retirement notice explains that the app was removed across the Winter ’26 and Summer ’26 release cycle, with Salesforce shifting attention to newer tools. A current health review therefore needs several sources of evidence rather than a single score or report.
Treat old Optimizer findings as one historical signal. Pair them with Health Check for security settings, Org Check and Code Analyzer for Salesforce technical debt, Scale Center and Lightning Experience Insights for Salesforce performance monitoring, dependency checks for change risk, audit history, data-quality checks, integration telemetry, and user evidence. A healthy org keeps working safely as data, users, automation, and business rules change.
Salesforce Optimizer Is No Longer a Current Org Health Tool
Salesforce Optimizer has been retired, so it should not be presented as a current tool that every admin can open in Setup. Salesforce states that the app was retired first for Hyperforce organizations with Winter ’26 and then removed for remaining organizations during the 2026 release cycle. Users in newer orgs had already lost access earlier. Salesforce also published guidance for working without Salesforce Optimizer, which points admins toward individual Setup areas for storage, security, release updates, external access, and other checks.
That change exposes something that was always true: the app grouped several observations into one place, but it did not own the underlying health of the org. Security settings still lived in security tools. Performance evidence still came from runtime behavior. Code quality still required source analysis. Adoption still depended on what users did. Integration reliability still depended on systems outside Salesforce as well as Salesforce endpoints.
If your team has an old Optimizer report, keep it as a baseline. It can show what the org looked like at a point in time and may help explain why later cleanup work was started. Do not use it as proof that the present org is healthy. Metadata, permissions, user behavior, integrations, release settings, and automation can change quickly. A 6-month-old diagnostic can be historically useful while being operationally stale.
The retirement also changes the way teams should think about “replacement.” There is no single screen that can truthfully answer every org-health question. The better model is a small set of checks, each tied to a specific risk area and repeated on a known schedule.
What Salesforce Optimizer Actually Measured Well
Salesforce Optimizer earned its place because it made a scattered admin problem easier to scan. It could highlight configuration and usage patterns that were otherwise easy to ignore. Typical findings included unused features, limits, permissions, hard-coded references, and other items that could create future work.
Those findings are still useful. Salesforce’s current AppExchange catalog lists Org Check by Salesforce Labs as a free tool for analyzing an org and its Salesforce technical debt. The focus is narrower: inspect metadata and debt instead of treating one broad report as the health verdict.
The app was strongest when the question was concrete. Are we close to a limit? Do we have configuration that deserves review? Are users adopting a feature? Is there a cleanup candidate an admin should inspect? These are measurable questions with relatively direct answers.
The weakness appeared when teams turned those answers into larger conclusions. A low field count does not prove a clean data model. Feature adoption does not prove that the business process works. Storage figures do not prove that archival rules are sensible. The tool surfaced evidence, but interpretation still belonged to the people who knew the system and its business use.
That distinction should carry into every modern assessment. A health check should separate observations from conclusions. “There are 42 active flows on Opportunity” is an observation. “Opportunity automation is safe to change” is a conclusion that requires dependency, execution, testing, ownership, and failure evidence.
Why a Good Score Can Still Hide a Sick Org
A healthy org is not the same as a tidy org. Tidy metadata can still sit on top of poor process design. A well-secured org can still be slow. A fast org can still contain risky permissions. A system with little visible technical debt can still fail users because the business process is confusing or because integrations lose records.
Salesforce’s current Well-Architected Framework makes this wider view explicit. It looks across trust, reliability, operational practice, resource use, cost, and fairness. That broader frame is useful because Salesforce org health is a property of the full solution, including how people run it, rather than a count of isolated configuration warnings.
Single-score thinking becomes dangerous when scores compress unlike risks into one number. They can help with triage, but they can hide severity. One critical exposure should not be averaged away by 20 harmless housekeeping wins. A broken integration that drops orders matters more than a collection of unused page layouts. A permission issue that exposes restricted data matters more than a group of fields without descriptions.
A better review uses categories and evidence. Each finding should answer 4 questions: What can fail? Who is affected? How would we detect it? What is the next safe action? That turns the review from a cosmetic cleanup exercise into operational risk management.
Architecture and Dependency Risk Stay Mostly Invisible
The hardest Salesforce problems often sit in dependencies. A field can look unused until a formula, integration mapping, Flow, Apex class, report, managed package, or external process depends on it. Deleting or changing that field can then break something that was not visible in a surface-level inventory.
Salesforce includes targeted dependency help. On supported custom fields, the Where Is This Used? function can show references such as formulas, Apex, validation rules, layouts, flows, and other metadata. It is useful, but an org-wide change-impact review still needs more context because business dependencies can live outside the metadata graph.
Consider a field called Renewal_Tier__c. It may appear on no page layout and have very low population. That looks like an easy cleanup candidate. An external billing process may still read it through an API query once per night. A downstream warehouse may use it in a transformation. A legal export may depend on it. None of those facts is guaranteed to be obvious from a field count.
Architecture risk also appears when responsibilities blur. One object may carry sales, service, finance, and partner logic because it grew over years. Teams then add another Flow because touching the old logic feels unsafe. The result may work today while becoming harder to test with every release.
A strong health assessment therefore includes a dependency map for high-risk objects and processes. Start with revenue, case handling, identity, billing, consent, and other flows where failure has real cost. Trace the objects, automation, code, integrations, scheduled jobs, events, and manual controls that participate. The purpose is not to map every corner of the org. It is to know where a small change can create a large blast radius.
Automation and Code Quality Need Separate Inspection
Optimizer could point at signs of complexity, but it could not prove that custom code and automation were safe. Code health depends on behavior that a configuration summary cannot fully judge: branching logic, bulk behavior, error handling, query patterns, test quality, duplication, security checks, and interaction between execution paths.
Salesforce now provides Salesforce Code Analyzer for static analysis across Apex, Visualforce, Flows, Lightning components, JavaScript, and related files. Its engines can surface security, performance, duplication, and code-quality issues. That makes it a useful input when Salesforce technical debt includes custom development rather than declarative configuration alone.
Automation needs a similar review. A count of flows is less useful than knowing which flows touch the same object, which run before save or after save, which call subflows, which perform queries in loops, and which have fault paths. Old Workflow Rules and Process Builder artifacts may also remain in mature orgs even after teams move new work to Flow.
The key question is change safety. Can a developer or admin explain the order in which automation runs for a critical transaction? Can the team test the main branches without relying on production users to find regressions? Are failures logged somewhere that an owner checks? If the answer is no, the org has risk even when current transactions appear to complete.
Code coverage can also mislead. Passing a platform coverage threshold is necessary for deployment in many Apex scenarios, but coverage does not prove good assertions, useful test data, or realistic negative cases. A test can execute a branch without proving the branch produces the correct business result. Critical logic therefore needs test-quality review; a coverage percentage is insufficient.
Real Performance Only Appears Under Real Workloads
Configuration health and runtime health are different. A design can look reasonable in Setup and still slow down when record volume grows, data skew appears, users run large reports, integrations spike, or several automation paths fire in the same transaction.
For current Salesforce performance monitoring, Scale Center provides org performance metrics and analysis for areas such as Apex, database activity, Flow performance, governor limits, integrations, and row locking. This type of runtime evidence answers questions an old Salesforce Optimizer snapshot could not settle: what is consuming resources now, when does it spike, and which entry points are involved?
Page experience deserves its own view. Salesforce’s Lightning Experience Insights reports page-performance and usage signals, including Experienced Page Time and percentile-based measures. A page may technically load without errors while still feeling slow enough that users avoid it or work around it.
Performance review should focus on the work users and systems actually perform. Pick the transactions that matter: creating an opportunity, converting a lead, saving a large quote, closing a case, processing an order, syncing a customer, or running a key batch. Measure them under realistic data conditions. Review slow queries, record locking, CPU pressure, API spikes, and page load patterns.
Salesforce performance monitoring also needs a time dimension. A single “looks fine” test at 10 a.m. says little about end-of-month loads or a nightly integration window. Compare normal periods with known busy periods and recent releases. Performance regressions are often easier to find when the team can say what changed and when the metric moved.
Security Health Requires More Than One Dashboard
Salesforce Health Check is useful, but its scope is specific. It compares selected security settings in the org with a baseline. That can reveal weak session settings, password policies, and other configuration differences. Salesforce documents the Security Health Check as a way to identify potential vulnerabilities in security settings and compare the org against a Salesforce or custom baseline.
A strong Salesforce Health Check score does not answer every security question. It does not automatically prove least-privilege access, correct record sharing, safe integrations, secure custom code, clean guest-user exposure, proper secrets handling, or compliant data retention. Those controls require separate evidence.
Start with access paths. Review profiles, permission sets, permission-set groups, roles, sharing rules, queues, public groups, connected apps, integration users, guest access, and privileged administrative permissions. Pay special attention to accounts that can bypass normal sharing through broad permissions.
Then look at activity. Salesforce’s auditing guidance covers login history, field history, Setup Audit Trail, Event Monitoring, and related controls. Activity evidence matters because a secure setting can coexist with suspicious behavior. Configuration tells you what should be possible. Audit evidence helps show what actually happened.
The final layer is exception management. Some teams intentionally accept a setting that differs from a standard baseline because of a documented business requirement. That can be reasonable. The risk appears when nobody can explain the exception, its owner, or the control that reduces its impact. Org health improves when security exceptions are explicit rather than accidental.
Data Quality Problems Are Business Problems First
Data health cannot be reduced to storage usage or duplicate counts. An org can stay comfortably below storage limits while containing records that users do not trust. A field can be 98% populated and still be wrong. A duplicate rule can be active while duplicates continue to arrive through another channel.
Salesforce provides duplicate-management tools that use matching rules, duplicate rules, jobs, record sets, and merge actions. These controls help, but they only cover part of overall org health. Data quality also includes accuracy, completeness, timeliness, consistency, ownership, and whether a field still has a useful business definition.
Start with critical data elements rather than every field. Which values drive routing, forecasting, billing, entitlement, compliance, segmentation, renewal, or reporting? For each one, ask where it comes from, who can change it, what validation applies, how often it becomes stale, and which downstream systems consume it.
A common failure is the “required but meaningless” field. Users cannot save without entering a value, so they choose a placeholder that satisfies the rule. The field becomes complete in a technical sense while becoming useless for analysis. The old tool could never resolve that because the problem is semantic. You need user interviews, report sampling, and process knowledge.
Data lifecycle also belongs in the review. Determine what should be retained, archived, anonymized, merged, or deleted. Old records can increase query cost and user confusion even when storage is available. Sensitive data that has outlived its purpose can create security and compliance exposure. A good review asks whether data is worth keeping and whether its retention still has a purpose.
Integration Health Lives Beyond Salesforce Setup
An org can look healthy while its integrations fail quietly. A nightly job may skip records, an external endpoint may time out, retries may create duplicates, or a middleware queue may build up. None of those conditions is fully described by an internal configuration scan.
API consumption is one useful signal. Salesforce explains API limits and monitoring across Setup, response headers, the Limits resource, and usage notifications. Monitoring consumption matters because unexpected growth may point to an inefficient integration, a retry storm, a new workload, or a process that has started calling Salesforce far more often than planned.
The deeper review is transaction-based. Pick an important integration journey and follow one record end to end. Confirm how it is created, transformed, sent, acknowledged, retried, reconciled, and surfaced when it fails. Check whether correlation IDs or external IDs allow teams to trace a record across systems.
Failure handling deserves special attention. If an API call fails after Salesforce commits a transaction, what repairs the mismatch? If the external system succeeds but the response is lost, can a retry create a duplicate? If a credential expires, how quickly will someone know? These are reliability questions, not merely connector settings.
Technical debt can also accumulate at integration boundaries. Hard-coded endpoints, old API versions, user-specific credentials, undocumented mappings, and tightly coupled point-to-point jobs raise change cost. A modern org health review should score integration ownership and observability alongside internal metadata.
User Adoption Can Hide Poor Process Fit
Usage numbers are helpful, but they can be misunderstood. A high login rate proves that people enter Salesforce. It does not prove that they complete the intended work efficiently or that the data they enter is useful. Users may log in every day and still maintain private spreadsheets because Salesforce makes a key task too slow.
Salesforce’s Lightning Usage App exposes adoption and usage metrics such as active users, page visits, browser use, and slower record pages. Those signals can help teams decide where to investigate. They become much more useful when paired with business-process evidence.
Look for workarounds. Repeated CSV exports, manual re-entry, spreadsheet trackers, copy-and-paste steps, duplicate reports, and frequent requests for admin help all suggest process friction. None should be dismissed as “user resistance” until the workflow is examined.
A practical review compares system design with the real job. Watch a few users complete a high-value task. Count the screens, required decisions, repeated entries, and moments when they leave Salesforce. Ask where they hesitate and what they do when data is missing. That evidence can reveal a poor page design or a process rule that no configuration score will flag.
Adoption should also be segmented. A global percentage can hide one region, role, or team with serious problems. Compare use by function and process. If sales adoption is high but service agents bypass a critical workflow, the org has a health issue even when the overall dashboard looks respectable.
Change History and Governance Reveal Whether Health Will Last
An org can be healthy today and become hard to manage within months if change control is weak. Governance determines whether good conditions persist after the assessment ends.
Salesforce provides Setup Audit Trail to show recent administrative and configuration changes. That history is valuable when several admins work in the same org or when a new issue appears after a configuration change. It should be part of incident diagnosis and periodic review, not something opened only after an audit request.
Governance starts with ownership. Critical objects, integrations, automations, reports, and permission models need named owners. Ownership should include the authority to approve changes and the responsibility to keep documentation and tests current.
Release practice is another health signal. Ask how changes move from development to production, how conflicts are handled, how regression tests run, and how rollback decisions are made. An org where production is the main testing environment carries risk even when current metadata looks clean.
Technical debt often grows from emergency changes that never receive follow-up. A one-time field becomes permanent. A temporary Flow remains active. A duplicate permission set stays because no one knows whether it is safe to remove. Governance should include a debt register with owner, impact, evidence, and review date. That makes cleanup part of normal delivery rather than an annual project.
A Modern Salesforce Org Health Assessment Needs Multiple Lenses
A useful assessment should combine tools rather than searching for one successor to the retired app. The exact set will vary by edition, licensing, custom development, and business risk, but the review should cover the same broad questions.
| Health Area | Evidence To Review | What A Weak Result Usually Means |
| Security | Salesforce Health Check, access model, login and audit evidence | Excess access, weak settings, or poorly governed exceptions |
| Architecture | Dependency maps, object ownership, automation paths | Changes can have unknown side effects |
| Code and automation | Org Check, Code Analyzer, Flow review, test evidence | Technical debt is increasing change risk |
| Performance | Scale Center, page metrics, load tests, runtime logs | Real workloads are approaching limits or slowing users |
| Data | Duplicate review, field sampling, data definitions, retention | Users cannot rely on records or lifecycle rules |
| Integrations | API use, failure queues, retries, reconciliation | Cross-system processes can fail without fast detection |
| Adoption | Usage metrics, task observation, support themes | People are working around the intended process |
| Governance | Audit trail, release process, ownership, debt register | Improvements will decay after the assessment |
For architecture and operations, Salesforce’s Operational Excellence guidance treats monitoring, deployment safety, incident response, and operating discipline as part of solution quality. That is the right mindset for an org-health program: health should be observable and maintainable, not inferred from a one-time scan.
The assessment should also separate severity from effort. A high-risk permission problem may take 30 minutes to fix, while a medium-risk automation refactor may take 3 sprints. Rank first by impact and likelihood, then plan delivery around dependencies and effort.
How to Run the Assessment in Practice
Start with scope. Define the business processes and org areas that matter most. A global inventory is useful, but critical workflows deserve deeper review. If the org supports lead-to-cash, service, partner operations, or regulated data, name those flows before opening any tool.
Next, collect current evidence. Run Salesforce Health Check, Org Check if appropriate, Code Analyzer on source, Salesforce performance monitoring tools, access reports, audit history, API usage checks, and data-quality reports. Record the date and environment for each result. A sandbox finding can differ from production because data volume, integrations, and permissions differ.
Then test critical journeys. Scale Center can compare runtime behavior across time ranges, which helps connect busy periods or release changes with performance shifts. Use those signals while running representative user and integration flows.
After that, interview owners and users. Tool findings need explanation. An “unused” field may have a quarterly purpose. A broad permission may support an emergency team. Context can change the correction, but it should not erase evidence without a documented reason.
Now classify findings. Use a simple set such as critical, high, medium, and low, with a short reason tied to business impact. Avoid creating a single score that hides the nature of the risk. Group related findings under the root cause when possible. For example, 8 failing automations caused by one shared integration pattern should be treated as one architectural problem with several symptoms.
Finally, turn findings into owned work. Every accepted issue should have an owner, target state, next action, and proof of completion. “Review permissions” is too vague. “Replace Modify All Data access for the support integration user with the documented minimum permissions, validate in full-copy sandbox, then confirm successful nightly sync” is testable.
What to Review Monthly, Quarterly, and Before Major Change
Org health improves when checks happen at the pace of risk. Some signals change daily, while others need a deeper review less often. A fixed cadence prevents teams from treating health as a one-time cleanup project.
Monthly work should focus on operational drift. Review critical integration failures, API use, storage trends, privileged-user changes, major automation errors, slow user journeys, and unresolved incidents. If Salesforce performance monitoring shows a new spike, investigate it while the release or workload change is still fresh.
Quarterly work should go deeper. Re-run Salesforce Health Check, sample permissions, review Salesforce technical debt, inspect stale fields and automation, confirm business owners, review data-quality measures, and revisit the debt register. Also check whether recurring support tickets point to a design problem rather than a training problem.
Before a major release, migration, merger, or new integration, increase the depth. Map dependencies, compare performance before and after, test bulk and failure scenarios, review security changes, and confirm recovery steps. If the change touches a revenue or regulated process, require clear acceptance evidence from both technical and business owners.
The point of cadence is to catch drift early. A single new Flow is easy to understand. Twelve unreviewed Flows added across 9 months are harder. One temporary permission is easy to remove. A collection of undocumented exceptions becomes part of the access model. Routine review keeps small debt from turning into structural Salesforce technical debt.
Conclusion
Salesforce Optimizer was useful because it made visible problems easier to find. Its biggest limitation was that teams could mistake a collection of findings for a complete statement about org health. The app’s retirement makes that mistake easier to avoid because there is no longer one report to lean on.
Current Salesforce org health needs evidence from several places. Salesforce Health Check covers a security baseline. Org Check and Code Analyzer help expose Salesforce technical debt. Scale Center and Lightning Experience Insights support Salesforce performance monitoring. Dependency inspection, audit history, integration telemetry, data review, and user observation fill gaps that configuration tools cannot close.
Change safety should replace scorekeeping as the main standard. A healthy org is one whose critical processes are understood, monitored, owned, and testable. Teams should know what can fail, how they will notice, and who is responsible for fixing it. That standard tells you far more about the health of a Salesforce environment than an old Optimizer report ever could.
FAQs
Is Salesforce Optimizer Still Available in 2026?
Salesforce retired the Optimizer app across its 2025 and 2026 release cycle. Availability depended on infrastructure and release timing during the transition, but teams should now use current Salesforce tools and focused assessments rather than plan around Optimizer as an active org-health product.
What Replaced Salesforce Optimizer?
There is no single replacement that covers every old use case. Salesforce points admins toward individual Setup checks and newer tools. Org Check can help with technical-debt analysis, Health Check covers security settings, and Scale Center covers runtime performance concerns.
What Is Salesforce Org Health?
Salesforce org health describes how safely and reliably an org supports its business processes over time. It includes security, architecture, code, automation, performance, data quality, integrations, user experience, change control, and ownership.
Is Salesforce Health Check the Same as Salesforce Optimizer?
No. Salesforce Health Check focuses on security settings and compares them with a baseline. The retired app covered a wider set of configuration and usage observations. Neither should be treated as proof that every part of an org is healthy.
Can a High Health Check Score Still Hide Security Risk?
Yes. A strong score can coexist with excessive permissions, unsafe custom code, weak integration credentials, poor guest access, risky sharing, or suspicious user activity. Those areas require separate review and evidence.
How Do I Find Salesforce Technical Debt?
Start with metadata and code analysis, then add dependency and ownership context. Review old automation, duplicated logic, unused fields, aging API versions, hard-coded references, weak tests, undocumented integrations, and changes that teams avoid because they are hard to understand.
What Should I Check for Salesforce Performance Monitoring?
Review runtime metrics, slow transactions, page experience, database activity, governor-limit pressure, API use, locking, Flow behavior, Apex behavior, and performance before and after releases. Measure important user and integration journeys under realistic load.
Does Salesforce Optimizer Detect Bad Business Processes?
No automated configuration report can reliably decide whether a business process makes sense. That requires user observation, process ownership, business outcomes, exception patterns, support themes, and evidence about how work is completed in practice.
How Often Should I Review My Salesforce Org?
Review fast-changing operational signals monthly, perform a deeper cross-functional review quarterly, and run targeted assessments before major releases, migrations, mergers, audits, or new integrations. High-risk environments may need a tighter cadence.
Should Unused Fields Be Deleted Immediately?
No. Treat them as candidates for review. Check metadata references, integrations, reports, exports, business cycles, and retention needs before removal. A field with low use can still support an important quarterly or downstream process.
How Do Integrations Affect Org Health?
Integrations affect reliability, data quality, security, and API capacity. A healthy integration has clear ownership, monitored failures, safe retries, reconciliation, traceable records, current credentials, and documented mappings between systems.
What Is the Biggest Weakness of a Single Org Health Score?
A single score can average unlike risks together. Several minor cleanup wins can make the number look good while one serious security, reliability, or integration issue remains. Category-level findings preserve severity and business context.
Can Code Coverage Prove Apex Is Healthy?
No. Coverage shows that tests execute code, but it does not prove strong assertions, realistic test data, bulk safety, negative-case handling, or correct business outcomes. Critical code needs a deeper test-quality and static-analysis review.
What Should Be Included in an Org Health Report?
Include scope, dated evidence, findings by risk area, business impact, severity, owner, target state, next action, dependencies, and proof needed for closure. Keep observations separate from conclusions so reviewers can see why each decision was made.
How Do I Know Whether My Salesforce Org Is Healthy After Cleanup?
Re-test the critical journeys and compare the evidence that led to each finding. Confirm that security access is correct, runtime performance is stable, integrations reconcile, users can complete work, and closed issues stay closed after later releases.
