The two weeks nobody enjoys
Almost every Salesforce project opens the same way. Two weeks of discovery: someone exports metadata, someone else interviews stakeholders, a consultant assembles it into a slide deck, and the deck says your org has technical debt.
Everyone already knew that. What the deck usually cannot tell you is which debt is in the way of the thing you are trying to build, what breaks if you touch it, and which of it you can safely ignore. So the findings get filed, the project proceeds on assumptions, and the assumptions surface as change requests in week seven.
We ran that process enough times to get tired of it. So we built the tool we wanted: OrgScan.
What OrgScan is
OrgScan connects to a real Salesforce org through OAuth and answers three questions:
- What is in here? — inventory and health scores, with every finding backed by evidence
- What depends on what? — a dependency explorer that isolates the blast radius of any component
- What happens if we change this? — an agent that plans a specific change against your actual org and stops for your approval
It replaces the discovery deck with something you can interrogate.
How the scan works
The scan pulls inventory through the Tooling API across the metadata types that actually accumulate debt: Apex classes, Apex triggers, flows, validation rules, permission sets, and custom fields.
Two details there matter more than they sound:
Managed packages are excluded. Anything with a namespace prefix belongs to an installed package, not to you. You cannot fix it, you did not build it, and for Apex the body comes back as the literal string (hidden) anyway. Counting it inflates every number and makes the report useless. OrgScan scopes to what your team actually built.
"Unused" is derived, not guessed. A component is marked unused when nothing references it in the org's real dependency graph — not because a naming convention looked stale. That distinction is the difference between a finding you can act on and a finding you have to go verify by hand.
There is also a quiet edge case worth mentioning because it is the kind of thing that silently corrupts a report: fields you delete sit in a roughly 15-day grace period, renamed with a _del suffix rather than removed. Count those and you are reporting debt that someone already cleaned up.
Every rule runs isolated. If one query fails — an object that does not exist in your Salesforce edition, a permission the connected user lacks — that rule is logged and skipped. The scan does not collapse because one check could not run.
What it looks for
Eight rules run against the connected org, spanning security, tech debt, complexity, adoption, and governance:
- Excessive Modify All Data — the permission that quietly defeats your entire sharing model
- Hardcoded Salesforce IDs — record IDs baked into code, the classic sandbox-to-production landmine
- Low code coverage — where deployments will fail before they start
- Orphaned Apex classes — code nothing calls any more
- Unused custom fields — fields nothing references
- Sparsely populated fields — fields that exist but are almost always empty
- Object field bloat — objects that have accumulated past the point of comprehension
- Inactive users holding licenses — the finding that usually pays for the engagement
That last one is not a joke. It is routinely the first thing a CFO reads and the reason a project gets funded.
Scores you are allowed to argue with
Every score traces back to a rule. There is no proprietary index and no vibes-based grading.
Each of the five categories starts at 100, and findings deduct by severity — critical costs the most, low costs least. But the deduction scales logarithmically with the number of findings at each severity rather than linearly, and that design decision is worth explaining because it is where most scoring systems fail.
Take unused custom fields. A large org can legitimately have 200 of them. Under linear deduction, that single rule drives the category to a flat zero — and so does an org with 40, and so does one with 800. Every org above about ten findings looks identical, and the score stops carrying information exactly when you need it to.
Log scaling keeps the categories separable: the first finding of a given severity costs the most and each additional one costs less. The result is a number that distinguishes "mildly untidy" from "genuinely alarming" instead of flattening both to zero.
Security is weighted double in the overall score. A beautiful org with a permissions problem is not a healthy org.
Missions: planning a specific change
Health scores tell you the state of the org. They do not tell you what happens if you build the thing you came to build. That is what missions are for.
You describe a change in plain language against a target object. The agent runs a fixed six-step plan:
| Step | Engine | Stops for you? |
|---|---|---|
| Find existing automation | Deterministic | No |
| Recommend an approach | Reasoning | Yes |
| Trace what this change touches | Deterministic | No |
| Check architecture principles | Reasoning | No |
| Surface tech debt in range | Deterministic | No |
| Draft the epic and stories | Reasoning | Yes |
The engine column is the part we consider non-negotiable. Deterministic steps are queries — walking the dependency graph, listing the triggers and flows a change could live in, reporting open findings on the components you are about to touch. Those are facts, and a language model should not be inventing them.
Reasoning steps are judgment — whether to extend existing automation or build new and why, whether the change violates your architecture standards, how to size the stories. Those genuinely benefit from a model.
Labelling which is which means you always know whether you are reading a fact or an opinion. Most AI tooling blurs that line, and blurring it is how teams end up trusting a confident sentence that was never grounded in anything.
The gates are the point
Execution halts at two steps and waits. Not a notification you can dismiss — the mission does not continue until you respond.
At a gate you can approve, or you can push back with context the agent did not have. Those refinements explicitly outrank the agent's earlier reasoning on the next pass. It is not a chatbot politely re-rolling the dice; the correction is treated as authoritative.
This is deliberate. An agent that plans changes to a production Salesforce org without a human confirming the approach is not a feature we want to ship.
What OrgScan deliberately does not do
Since we would rather you hear this from us than discover it in a demo:
It does not deploy anything. The final step drafts an epic and sized stories with test criteria. It stops there. OrgScan plans work; your team and your release process ship it. We have no interest in an agent that pushes metadata to production on its own judgment.
It does not replace discovery conversations. It replaces the two weeks of manual archaeology that used to consume discovery. Why your renewals process works the way it does, which stakeholder owns which decision, what your team has already tried — the tool cannot tell you any of that. Those conversations get better when nobody is spending them reading metadata aloud.
It does not make an unhealthy org healthy. It makes an unhealthy org legible. That is a precondition for fixing it, not a substitute.
What actually changes about delivery
Our published timeline has not moved: most Agentforce deployments still go live in 8 to 12 weeks, and we would be suspicious of anyone claiming otherwise. Building agents, testing them against real scenarios, and rolling them out safely takes the time it takes.
What changes is where the time goes.
| Traditional discovery | With OrgScan | |
|---|---|---|
| Org audit | 1–2 weeks of manual export and analysis | One working session |
| Findings | A static document | Live, evidence-backed, re-runnable |
| Impact analysis | Estimated from experience | Traced through the dependency graph |
| Backlog | Drafted in week three | Drafted day one, refined by humans |
Two weeks of discovery collapses into a day, and those two weeks go back into building and testing instead. The engagement is not shorter by default — it is front-loaded. You know what you are dealing with before anyone commits to an architecture, which is the single best predictor of whether a project hits its date.
It also changes what a first conversation can be. We no longer have to say "we would need to look at your org." We can look at your org.
Availability
OrgScan is our own tool, built because the alternative was another two-week deck. We use it on our engagements today, and we are opening it up more broadly — if you want to be told when signup opens, say so on a call and we will put you on the list.
Or skip the list. Book a strategy call and we will run it against your org as part of the assessment. You keep the report either way.