Why it matters — and when to run one
Salesforce orgs rarely fail loudly. They degrade one small decision at a time: a field added for a single campaign and never removed, a flow cloned instead of refactored, an integration user given a wide profile "temporarily", a licence purchase made ahead of a rollout that slipped. Every individual decision was defensible. A few years of them produce a system that is slower to change, harder to trust and more expensive to run than it needs to be.
Because the degradation is gradual, the people closest to the org are the least able to see it. Admins have normalised the workarounds; users have stopped reporting problems and started keeping spreadsheets. A health check reintroduces an outside baseline: what a well-run org of this size and age should look like, and where yours diverges. Common triggers:
- Sales and finance report different numbers from what is supposedly the same pipeline.
- Users export data to spreadsheets to do their real work, then paste results back in.
- Small changes take weeks because nobody can predict what a change will break.
- Record saves are slow, pages time out, or lock errors appear under end-of-quarter load.
- A renewal is approaching and nobody can say with confidence which licences and add-ons are actually in use.
- New leadership — a CIO, a RevOps lead, a lead admin — inherits the org and needs an honest starting point.
- A major programme is coming, such as a CPQ-to-Revenue-Cloud migration or an Agentforce rollout, and you need to know whether the foundation can carry it.
Timing matters. Run a health check before you commit budget to a large build, not after — remediating a weak foundation mid-project is the most expensive way to discover it. Orgs that have absorbed a merger, a re-org or several years of unreviewed change are the other classic candidates.
How Clouderia delivers a health check
The assessment is done by the same senior engineers who build and rescue Salesforce systems for a living — not by a junior analyst running a checklist. Clouderia has been doing this work since 2010, with 46 certified experts across offices in Provo and Prague, and delivery experience in telco, financial services, insurance, nonprofit, automotive and SaaS. That matters because most health-check findings are only useful when someone can tell you what caused them and what fixing them actually involves. The engagement runs in four phases:
1. Scope and access
We agree the questions the business wants answered, inventory the orgs and connected systems in scope, and set up read-only access: Metadata API extraction, adoption and usage reporting, and a recent full-copy sandbox where one exists. Nothing is changed in your org at any point.
2. Evidence gathering
We extract metadata and code, build an automation inventory per object, sample debug logs and limit consumption, profile the data, and pull adoption analytics. Configuration and Apex get an engineering read, not just a scan — the approach we describe in our Salesforce code review guide. In parallel we run short structured interviews with admins, developers, operations staff and a handful of frontline users, because the org as documented and the org as used are rarely the same system.
3. Analysis and scoring
Findings are mapped to the five dimensions and scored, each with the evidence behind it. We separate symptoms from causes — slow pages are a symptom; six automation layers firing on the same object is a cause — so the remediation plan attacks roots rather than repainting surfaces.
4. Readout and roadmap
We walk your team through the findings in a working session, deliver the written report, and leave you with a remediation backlog ordered by business impact and effort: quick wins your admins can ship next week, and structural work that needs planning.
Two things we deliberately do not do. We do not touch the org — the check is read-only from start to finish. And we do not write the report as a sales document: where the honest finding is "leave this alone" or "you are paying for more than you use", that is what the report says.
What a health check inspects
The five dimensions below are assessed together because they interact: poor adoption produces poor data, technical debt produces poor performance, and all of them distort what your licence spend is actually buying.
Adoption and usage
Login history says almost nothing; we look at meaningful usage. Which objects and fields are actually populated by which roles. Which flows, reports and dashboards run, and which exist only in metadata. Where list views and exports are being used as workarounds for missing functionality. Whether the sales process configured in the org matches the process the interviews describe. Low adoption is rarely a training problem — it is usually a signal that the system fights the way people work, and the inspection is designed to find where.
Data quality
We profile duplication, completeness of the fields your forecasting and reporting depend on, stale and ownerless records, and referential hygiene — orphaned contacts, accounts outside any hierarchy, picklists that have accumulated years of near-duplicate values. Integration-created records get particular attention, since a misconfigured sync can quietly manufacture bad data faster than any team of users. The output is not a lecture about data discipline; it is a map of which quality problems actually distort decisions and which are cosmetic.
Performance
Perceived slowness usually has identifiable causes: record pages carrying too many components and fields, multiple automation layers stacked on the same object with nondeterministic ordering, SOQL patterns that degrade as data volumes grow, data skew concentrating child records under a few parents, and lock contention that only appears under month-end load. We also review storage growth and API consumption trends qualitatively, and flag where current design will collide with platform limits as volume increases — before it does so in production.
Technical debt
Unused fields and automations, code without tests or with tests that assert nothing, hard-coded IDs, abandoned managed packages, permission sprawl, sandboxes that no longer resemble production, and the org-wide fear of deleting anything because nobody knows what depends on it. We catalogue the debt, but more importantly we classify it: debt that is actively taxing every change, debt that is dormant but dangerous, and debt that is cosmetic. The rescue pattern for the serious cases is described in our technical-debt rescue guide.
Licence utilisation
Assessed qualitatively: we compare what you are licensed for against what is demonstrably used. Typical patterns include inactive or departed users still holding full licences, add-on clouds purchased for an initiative that never launched, feature licences assigned broadly but exercised narrowly, and licence types mismatched to what a role actually does in the system. We do not resell licences and have no stake in your Salesforce contract, which makes the findings useful leverage at renewal time — whichever direction they point.
Typical findings
Most orgs that reach us share a recognisable pattern set. The specifics differ; the shapes repeat:
- A large share of custom fields on core objects that no process reads or writes any more.
- Triggers, workflow rules, process builders and flows coexisting on the same object, migrated halfway and never consolidated.
- Integration users with wide profiles, long-lived credentials and no owner.
- Reports and dashboards that no longer match how the business measures itself, so decisions happen in exported spreadsheets.
- Test coverage that satisfies deployment gates without asserting any behaviour.
- Ownership skew and parent-record hot spots producing lock errors that everyone has learned to retry past.
- Paid features switched on and never adopted, sitting invisibly in the renewal baseline.
Individually these findings are unglamorous. The value of the health check is not discovering any single one of them — a free scanner can list unused fields — but establishing which of them are actually costing you money, speed or trust, and in what order to deal with them.
Health check vs architecture review
The two engagements are related and often confused. A health check is broad and current-state: it measures how the org is doing today across all five dimensions and answers "what should we fix first?". An architecture review is deep and forward-looking: it examines the design itself — data model, integration patterns, automation architecture, org strategy — and answers "will this design carry the next three years of plans?".
Choose a health check when the symptoms are diffuse: things feel slow, trust in the data is eroding, costs are creeping, and you need a full-width baseline before deciding anything. Choose an architecture review when you already know where the pressure is — a migration, a new integration layer, a product launch — and need the design of that area evaluated against the load it is about to take. In practice they sequence naturally: a health check frequently surfaces one or two domains whose findings justify a dedicated architecture review, and its report will say so explicitly rather than padding the scope. Security sits alongside both: a health check flags obvious access and permission issues it encounters, but a dedicated security review goes materially deeper on sharing model, exposure and credentials.
Deliverables and next steps
Every health check ends with the same concrete package:
- Scored report — each of the five dimensions assessed and scored, with the reasoning written out, not just a traffic light.
- Evidence appendix — the extracts, inventories and profiling behind every finding, so nothing rests on our say-so.
- Prioritised remediation backlog — findings ranked by business impact and effort, split into quick wins and structural work.
- Licence utilisation observations — qualitative, contract-neutral input for your next renewal conversation.
- Readout workshop — a working session with your team to contest, confirm and internalise the findings.
What happens next is your call, and the report is written to support all three routes: your in-house team works the backlog on its own; we run a focused remediation engagement on the highest-impact items; or the backlog folds into ongoing managed services, where debt is worked down release by release alongside new feature work. If the findings point at a deeper design problem, the honest next step is an architecture review of that domain — and the report will say exactly that. Whichever route you take, start the conversation through our contact page and we will scope it in a single call.
Frequently asked questions
How long does a Salesforce health check take?
Duration scales with the size of the org and the number of integrations and business units in scope. A single-org check is usually measured in weeks, not months, from access being granted to the readout workshop. The main variables are stakeholder availability for interviews, how many connected systems need to be traced, and whether more than one production org is involved.
What access do you need to run a health check?
Read-only access to production or a recent full-copy sandbox, including Metadata API access so we can extract configuration and code, plus standard adoption and usage reporting. We also ask for short interviews with admins, developers and a handful of frontline users. We make no changes to the org during the assessment — everything is analysed offline against extracted evidence.
How much does a Salesforce health check cost?
Cost is driven by org size and age, the number of integrations and connected systems, how many business units and orgs are in scope, and how deep the interview programme needs to go. We scope it in a short call and quote a fixed price for a defined deliverable, so there is no open-ended time-and-materials exposure. A single-org check is a bounded, predictable engagement.
Will a health check disrupt our team?
Minimally. The technical analysis runs against read-only extracts, so nothing changes in your org and no release windows are affected. The only time we ask of your people is a set of short, structured interviews with admins, developers, operations staff and selected end users, plus attendance at the readout workshop at the end.
Is Salesforce Optimizer or a free scanner enough?
Optimizer and static-analysis scanners are a good starting point and we use similar tooling ourselves. What they produce is raw signal: unused fields, limit warnings, rule counts. They cannot tell you which findings matter to your business, what caused them, or what order to fix them in. A health check adds human judgement, interviews and cross-system context on top of the tooling output.
Do we have to fix everything the health check finds?
No. The report ranks findings by business impact and remediation effort, and it is normal for some findings to be explicitly accepted as known risks. The goal is an honest baseline and a defensible priority order, not a maximal work order. You own the decisions; the report is written so you can act on any subset of it.
Can Clouderia fix what the health check finds?
Yes. Findings can flow into a focused remediation engagement or into ongoing managed services, where the backlog is worked down release by release. Equally, the report is written to be actionable by any competent team — including your in-house admins and developers — so commissioning the check carries no obligation to buy the fix from us.