ChatGPT
Claude
PerplexityFor fifteen years, understanding a Salesforce org meant assembling a toolkit. One tool for unused fields. Another for security settings. A third for static code analysis. A fourth for dependencies, a fifth for adoption dashboards, a spreadsheet to hold it all together, and a consultant to interpret the result.
That toolchain is now visibly falling apart, and not because the tools got worse. Salesforce Salesforce itself has started retiring the pieces, and because the questions businesses now ask of their orgs have outgrown what any single-lens tool can answer.
This is the story of what each tool covered, what has been retired, and why AI-driven analysis makes the entire assembly unnecessary.
Org analysis was never one discipline. It was six tools taped together.
Ask what is really happening inside a Salesforce org and you are actually asking six different questions: what exists, what is used, what is safe, what is well built, what is at its limits, and what it all costs the business. The ecosystem answered each with a different instrument.
Salesforce Optimizer was the closest thing to a native org analysis report. It flagged unused fields, unassigned page layouts, inactive validation rules, profile sprawl and limit consumption. It is gone. Orgs created after 31 March 2025 never received it, and the Winter ’26 release removed it for everyone else. Salesforce’s replacement guidance, published under the title “Optimization without Salesforce Optimizer”, splits the old report’s functions across Setup pages and third-party channels. The official successor is Org Check, a Salesforce Labs project shipped as an AppExchange app and an sf CLI plugin: useful, free, and by its own definition a scanner rather than an assessment.
Security Health Check survives, but it was never an org analysis tool. Salesforce’s own documentation for Security Health Check scopes it precisely: identify and fix vulnerabilities in security settings, from a single page. Password policies, session settings, sharing defaults, login access. The score is a comparison against a baseline, weighted by risk category. It tells you nothing about how many flows fire on Opportunity, whether your Apex compiles against the current API version, or which fields nobody has touched since 2022.
Static code analysis tools read the codebase and flag rule violations. Salesforce Code Analyzer is the native example, a unified tool that runs in the Salesforce CLI, VS Code, GitHub Actions and DevOps Center Testing, bringing together scanning engines including PMD and RetireJS. Powerful within their lane, blind outside it. A static analyzer sees an Apex class. It does not see the flow that duplicates the class’s logic, the integration that depends on it, or the business process it exists to serve.
Dependency and impact tools map what touches what, at the metadata level. DevOps platforms track what changed and when. Adoption dashboards count logins and page views. Each answers its one question. None of them talk to each other, and the developer experience of running an assessment is stitching their outputs together by hand.
The result was predictable. A proper org assessment became a one-week, two-person engagement covering extraction, correlation, interpretation and report, and it was obsolete within a quarter because the org kept changing while the document did not.
The tools were never the problem. The seams between them were.
Every serious org finding lives in a seam that no single tool can see.
An integration user with Modify All Data is a line item in a security review. The same finding becomes urgent when you know that user authenticates a callout with no retry handling, sitting under the order fulfillment process, on an object where a flow and an Apex trigger both write the same field. Four tools each hold a quarter of that sentence. The finding is the sentence.
A field with no recent history is a cleanup candidate in Optimizer’s old report. Whether it can actually be deleted depends on whether a report filter reads it, an integration payload carries it, and a team three time zones away keys a manual process off it. The delete decision lives across data, metadata and usage at once.
This is why the pile of tool outputs never became a decision. Tools produce component-level facts. Businesses need system-level judgment. Bridging that gap was the expensive human part, and it is precisely the part AI now does.
What changes when one agent reads everything at once
GetGenerative.ai built its Org Review Agent on a simple architectural bet: give a single AI agent live, read-only access to the data, the metadata, the codebase and the setup configuration at the same time, and the seams disappear. The agent inventories metadata, extracts source XML, maps dependencies, reads the automation and the code as one system, and translates all of it into natural-language documentation with every finding linked back to the source component that proves it.
Read-only by default, customer-controlled access, no production changes without approval. The point is not another scanner. The point is that the six questions that used to need six tools now get answered by one system that can hold them together. Here is what that makes possible, starting with the analyses the old toolchain could not perform at all.
Adoption health check
Adoption tooling counted logins. An agent with simultaneous access to data and metadata measures something different: whether the business process as designed is the business process as run. It traces an end-to-end journey, a lead-to-cash flow for example, and reports where users follow the designed path and where they route around it: stages skipped, fields left empty at the moment they mattered, records created through side doors the process never anticipated. The same lens applies to case management, data quality regimes, and any process the org was built to run. Adoption stops being a login count and becomes a per-process, per-team finding with evidence attached: which teams have absorbed the platform, which are working against it, and where enablement investment should actually go.
Integration architecture review
Because the agent reads code, automation, objects and configuration together, it reconstructs the full integration picture: how each integration is built, what authenticates it and at what privilege, which business processes depend on it, what volume moves through it, and where the failure points sit. It surfaces exactly the seam-dwelling risks described above: the over-permissioned integration user, the callout with no error path under a revenue-critical process, two systems writing the same object with no ordering guarantee. The output is a system map with business impact and fragility scored, not a list of connected apps.
Deep code and configuration analysis
This goes past what static analysis alone can reach. The agent reads the entire repository file by file against architectural best practice, covering code quality, configuration quality, standards violations, logic leaked between layers, and patterns that survive today’s volume but break at tomorrow’s. Because it sees code and configuration side by side, it catches the class of problem single-lens scanners structurally miss: automation duplicated between flow and Apex, hard-coded references that will not survive a sandbox refresh, bulk-unsafe logic waiting for the first mass data load. Every finding lands with the reason it matters and the shape of the fix.
Reverse-engineered org documentation
Most orgs run on documentation that stopped being true several release cycles ago, if it existed at all. The agent rebuilds it from the one source that cannot lie: the org itself. It stitches objects, fields, data and automation into generated business-process diagrams, entity relationship diagrams, automation maps, integration architecture and security-access maps. The org is explained in business language, derived from metadata rather than memory. Teams can then interrogate it directly: what updates Opportunity Stage? Which processes depend on this field? Show me every automation that can change Opportunity Amount and the systems affected downstream. Documentation becomes something you query, and because the agent can re-run continuously, it stays true as the platform changes.
Migration assessments
For teams weighing a platform move, whether an older quoting solution to the current revenue platform or a horizontal cloud to its industry-specific successor, the agent runs the fit-gap between what has been built and the capabilities of the target: which customizations the new platform absorbs natively, which need rebuilding, which should be retired rather than carried across, and where the data model translates cleanly versus needs rework. From that it sequences how migration and activation would actually run: what moves first, what runs in parallel, where risk concentrates. What used to be a multi-week paid discovery engagement becomes an assessment artifact produced from the org as it stands.
Legacy architecture identification
Orgs accumulate yesterday’s best practice, and nobody circles back to retire it. With current industry knowledge and live research capability, the agent compares the org against what the ecosystem does now: superseded patterns, products running past end-of-life, workarounds built for platform limitations that no longer exist, decisions that were right five years ago and are liabilities today. Each finding arrives as a fit-gap against the modern approach with the target solution attached. It is not a diagnosis that the org is dated, but the specific path to current.
One review, twelve lenses, three audiences
The agent evaluates the catalog it builds through twelve review lenses. They are architecture and design quality, technical debt, security and access, data quality and model, automation quality, performance and scalability, integration health, usage and adoption, release health and environment drift, maintainability, business-process fit, and AI and Agentforce readiness, with everything assessed against Salesforce Well-Architected principles.
And because one report satisfying everybody satisfies nobody, the output splits by audience. Leaders receive the Overall Health Check: an executive scorecard, risk summary, value leakage, critical findings heatmap and a phased roadmap, with every score linked to the findings and source metadata behind it. Architects and admins receive the evidence layer: the technical debt inventory, which is the artifact behind measuring technical debt, the Well-Architected alignment review, the searchable metadata catalog with natural-language descriptions and XML. Remediation teams receive focused worklists that export straight into a delivery backlog, which is where planning an org cleanup begins. The roadmap itself phases naturally: stabilize and de-risk in the first ninety days, simplify and strengthen over three to nine months, modernize and re-platform beyond that.
The last tool the old model could never ship: the one that keeps watching
Here is the deepest flaw in toolchain-era org analysis, deeper than fragmentation: every output was a photograph. The org kept moving the moment the report was rendered. New releases, configuration changes, shifting volumes, permission updates and integration failures all move an org quietly toward risk, and periodic reviews reveal only a moment in time.
Org Monitoring AI closes that gap. The monitors cover the same ground as the review lenses, covering metadata and configuration drift, automation health, data quality, security and access, performance and limits, integrations, releases, adoption, and business outcomes like conversion and SLA trends. Custom monitors are built from a plain-language objective rather than query writing. Describe the risk, and the AI suggests the signals, baselines and conditions. The final rule stays visible and under your control.
When a monitor trips, the alert does not die in a channel. It becomes a structured ticket in the Support Agent, carrying the evidence forward: affected scope, correlated changes, likely root cause and recommended resolution. Recovery is verified against the originating monitor. Signal, context, ticket, triage, resolution, verified recovery. The assessment stops being an event and becomes a state the org is kept in, which is the one deliverable the old toolchain was structurally incapable of producing.
Where to start
The entry point is an Org Review. Authorize read-only access, define scope and objectives, and receive the health check, the technical debt assessment, the living documentation and the remediation roadmap, with monitors added afterward so the picture never goes stale. Teams typically start one before a transformation, after years of accumulated change, following team or partner turnover, ahead of a major release, during an audit, or when Salesforce ROI has become hard to explain.
The toolchain era gave you six instruments and left you to be the system that connected them. That job now belongs to the agent, working alongside the Forward Deployed Engineers who act on what it finds.
Questions teams ask about Salesforce org analysis
Is Salesforce Optimizer still available?
No. Orgs created after 31 March 2025 never received the app, and the Winter ’26 release retired it for all remaining organizations. Salesforce published replacement guidance titled “Optimization without Salesforce Optimizer”, and the Salesforce Labs project Org Check, an AppExchange app and sf CLI plugin, is the recognized successor for metadata scanning.
What does Salesforce Security Health Check actually cover?
Security settings only. It compares your configuration against a baseline, by default the Salesforce Baseline Standard, weighted by risk category. It reports nothing about metadata volume, code quality, automation, adoption, data quality or limits.
Why do traditional org assessments require so many tools?
Because each tool answers one question: Optimizer-class scanners covered unused metadata, Health Check covers security settings, static analyzers cover code, dependency tools cover impact, and adoption dashboards cover usage. The findings that matter most sit in the seams between those views, which is the correlation work that historically required manual effort.
How is an AI-driven org review different from running these tools?
A single agent reads the data, metadata, codebase and configuration simultaneously, so findings arrive already correlated: an access risk connected to the integration it authenticates and the business process it endangers. Every finding links to the source metadata that proves it, and the analysis re-runs continuously instead of expiring.
Does the Org Review Agent make changes to the org?
No. Access is read-only by default and customer-controlled, findings are linked to source metadata, and no production change happens without approval.
Can the agent document an org nobody understands anymore?
Yes. It reverse-engineers living documentation from the org itself: natural-language explanations of every component, dependency maps, and generated diagrams covering business processes, entity relationships, automation paths, integration architecture and access models, all of it searchable and interrogable in plain English.
What happens after the review?
Findings become a phased remediation roadmap and can be exported into a delivery backlog. Org Monitoring AI then watches for drift, degradation and emerging risk, turning material alerts into structured support tickets with evidence attached and verifying recovery once resolved.
