SALESFORCE CONSULTANT DISCOVERY: WHAT TO REVIEW BEFORE RECOMMENDING CLEANUP.

A client says their Salesforce org is messy and asks for cleanup. They may mention too many fields, confusing permissions, too many Flows, old automation, failed imports, poor reporting, or general technical debt. The ask sounds familiar. It may even sound straightforward.

The consultant's first job is not to start deleting fields or rebuilding automation. The first job is to understand the org well enough to scope the work responsibly.

A cleanup recommendation without discovery is a guess. Discovery without a structured process is expensive to repeat.

Clients often ask for cleanup before anyone has enough evidence to scope the work accurately. Common asks include:

• Clean up unused fields — we have hundreds and nobody knows which ones matter
• Simplify permissions — we are not sure who can see what
• Fix automation — there are Flows everywhere and nothing is documented
• Review technical debt before we start a new implementation
• Prepare for a migration or import
• Improve reporting quality — too many fields are blank or duplicated
• Document the org for a new admin or team taking it over
• Onboard us onto managed services so you understand what you are inheriting

Each of these asks is valid. None of them can be scoped responsibly without first reviewing what is actually in the org.

The issue is not whether the consultant knows how to clean up a Salesforce org. The issue is that the first step has to be evidence, not opinion.

Consultants can collect org information manually. Most experienced Salesforce consultants have a personal process for this. The problem is that manual discovery is time-intensive, hard to standardize across engagements, and difficult to turn into a client-ready artifact.

Manual discovery often involves:

• Setup clicks through Object Manager for field review
• SOQL queries to check fill rates, distinct values, and record counts
• Metadata API exports or Salesforce Inspector-style browser tools for bulk field data
• Flow review in the Automation Builder
• Permission set and profile review across multiple Setup pages
• FLS review, which requires opening each permission set individually
• Report and dashboard review for downstream dependencies
• Stakeholder conversations to understand what was intentionally built vs inherited

The issue is not whether the consultant can do it. The issue is whether the process is repeatable, consistent, and client-ready without reinventing it for each engagement.

Salesforce consultants do not need diagnostic workbooks because they cannot review an org manually. They need them because first-pass discovery is repetitive, hard to standardize, and difficult to turn into a client-ready artifact. For more context on the scope of the problem, see the Salesforce Consultant Discovery Workbooks guide.

Clients are more likely to trust cleanup recommendations when they can see supporting evidence. The difference between a cleanup opinion and a cleanup recommendation is the data behind it.

Evidence-based findings sound different from opinions:

• "This field has 0% fill rate across 120,000 records." vs "This field looks unused."
• "This field is not on any layout but still has populated records." vs "This might be a hidden field."
• "This permission set grants edit access to margin and compensation fields." vs "Access looks broad."
• "This object has 14 active automations across Flows, Apex, and validation rules." vs "There is a lot of automation here."
• "This field is low-fill globally but 84% populated on the Enterprise record type." vs "Maybe this field matters."
• "This cleanup candidate has no supported reference signals, but integrations and managed package internals still need validation." vs "This is probably safe to delete."

Evidence helps consultants turn cleanup from a subjective opinion into a scoped review conversation. It also protects the consultant when a client later questions why a field was removed or a permission was changed.

One of the practical risks in a Salesforce cleanup engagement is scope creep. A client asks for field cleanup. The review reveals permission problems. The permission review reveals automation gaps. The automation review reveals import blockers. Without a structured discovery artifact, each finding leads to an informal scope expansion that is hard to document, price, or prioritize.

Diagnostic workbooks can help consultants avoid vague cleanup projects by supporting:

• Fixed-scope discovery: a bounded first engagement before cleanup begins
• Phased cleanup proposals: phase the work by priority, not by what the client asked for first
• Managed services onboarding: understand what you are inheriting before committing to SLAs
• Client handoff documentation: a structured artifact the client keeps after the engagement
• Stakeholder review: findings the client can share internally for validation and prioritization
• Risk documentation: a record of what was reviewed, what was not, and what still needs validation
• Before/after comparison: a baseline to reference when measuring the impact of cleanup work

For the inherited org context that often drives these engagements, see the Inherited Org Checklist and the Technical Debt Assessment.

Discovery produces findings, risks, candidates, and validation steps. It should not pretend every decision is already made. Consultants should avoid committing to outcomes that require information that has not been gathered yet.

Common overpromises to avoid:

• "All unused fields can be deleted" — field usage has multiple dimensions beyond fill rate
• "All permissions can be simplified quickly" — access review requires business owner validation
• "All automation can be untangled in one pass" — automation dependencies are not always visible from metadata alone
• "Metadata alone proves integration usage" — integrations may reference fields outside of what Salesforce metadata reports
• "Managed package internals can be fully inspected" — managed packages hide significant internal logic
• "AI can safely clean the org without review" — AI-generated changes still need a diagnostic layer before action

Discovery should produce findings, risks, candidates, and validation steps. It should not pretend every decision is already made.

For security and trust context when introducing a diagnostic tool to a client, see the Diagnostic Tool Security Checklist.

KeelCadence helps consultants turn first-pass Salesforce discovery into a review-ready XLSX workbook. Instead of starting from scattered Setup clicks, ad hoc SOQL, one-off exports, or undocumented tribal knowledge, consultants get a structured artifact they can sort, filter, share, and validate with the client.

When introducing a diagnostic workbook as part of discovery, consultants can frame it around scope and responsibility rather than product features:

This framing works across fixed-scope discovery engagements, managed services onboarding, admin handoff, and client inherited org reviews. It sets the expectation that the first step is review, not action.

Salesforce cleanup projects go better when discovery produces evidence, not just opinions. A review-ready diagnostic workbook helps consultants scope cleanup work, explain risk, and validate decisions before changing a client's org.

That workbook does not replace the consultant's judgment. It gives the consultant and the client a shared, structured artifact to work from. The consultant still validates business context, ownership, dependencies, and change impact. The workbook is the evidence layer that makes that validation faster, more consistent, and more defensible.