Salesforce org cleanup: start with the problems your team feels.

Start with one process people struggle to complete

Ask a user to show you a real task: qualifying a lead, moving a deal forward or handing over a won opportunity. Follow the work from start to finish. Note where they leave Salesforce, ask someone for context, enter the same information twice or hit an error.

An illustrative starting brief might be: sales managers rebuild the weekly pipeline report in a spreadsheet because stages and close dates are inconsistent. That is a specific problem you can investigate. A request to clean the entire org is much harder to scope.

• Which team owns the process?
• What should happen, and what happens today?
• Which records, reports and automations are involved?
• What would make the next review easier?

Separate unreliable data from unclear definitions

A report can disagree with another report even when neither is technically broken. They may use different date fields, filters, stage definitions or ownership rules. Agree on the business definition before rebuilding the dashboard.

Inspect a small set of relevant records. Check missing values, duplicate identities, inconsistent categories and unclear ownership. Prioritise the fields that drive a decision or an automation. Requiring every field on every record can make data entry harder without improving the result.

Trace automation before changing it

For the affected process, map the entry conditions, field updates and downstream actions. Review the active versions, error evidence and relationships between automation and validation rules. A field changed by one process may trigger another.

Several modular Flows can be a sensible design. The important question is whether their purpose, dependencies and execution order are understood. Counting Flows is not a diagnosis. Avoid a blanket redesign before you know which logic is causing the failure.

Check dependencies before removing clutter

An apparently unused field may still support a report, an integration or an automated decision. Check those dependencies and confirm the business owner before retiring it. The same applies to reports, layouts and old automation.

Simplify the user experience around the task you observed. Put the useful information where people need it, remove avoidable duplication and give each stage a clear meaning. Record why each change was made so the next administrator can maintain it.

Deliver a small fix with a clear acceptance test

Agree on a bounded change, test it in an appropriate non-production environment and let the users who perform the work validate it. Include relevant permissions, exceptions and bulk or integration updates in the test scope. Plan how to recover if the change behaves unexpectedly.

For the pipeline example, acceptance could mean that the agreed report reconciles with a reviewed sample and each active opportunity has an owner, a defined stage and a usable next step. That is evidence of an operational improvement; it does not prove a revenue increase.

Leave a system the team can maintain

A cleanup should leave a prioritised backlog, named process owners and short documentation for the critical paths. Keep a record of what changed, how it was tested and which recurring checks matter.

Review the baseline after the team has used the change. Track the relevant missing data, failed actions or manual reconciliation work. The aim is a process people can rely on, with enough ownership to prevent the same issue returning.