Mark
Salesforce Org Cleanup: Where I Would Start
Salesforce orgs rarely become messy all at once.
It usually happens gradually.
A field gets added for a temporary requirement. A Flow gets replaced but the old version remains. Permission sets accumulate. Reports multiply. Users leave. Page layouts grow. Someone creates another checkbox because changing the existing process feels risky.
None of those decisions necessarily look unreasonable at the time.
Years later, though, administrators and users can end up looking at an org where nobody is completely sure what is still needed.
When that happens, I wouldn't start deleting things.
I'd start by understanding what is actually there.
1. Start With Users and Access
One of the first places I'd review is user access.
Questions I'd ask include:
- Are inactive employees still active Salesforce users?
- Are there users who haven't logged in for a long time?
- Are permission sets still assigned for responsibilities people no longer have?
- Are profiles doing work that could be handled more cleanly with permission sets?
- Are there temporary access assignments that were never removed?
- Does the role hierarchy still reflect how the business operates?
This isn't only cleanup.
It's also a security review.
Removing an unused field might make an org easier to navigate. Removing access someone no longer needs can reduce actual risk.
That's why I generally put users and permissions near the beginning of an org review.
2. Look at Automation Before Changing It
Automation is another area where clutter can accumulate quickly.
An org may contain:
- Active Flows
- Inactive Flows
- Multiple versions of the same Flow
- Older Workflow Rules
- Process Builder automation
- Approval processes
- Apex
- Package automation
The number of automations isn't necessarily the problem.
The important question is whether anyone understands how they interact.
Before changing automation, I'd want to know:
What triggers this?
What records does it change?
Is another automation doing something similar?
Is it still supporting a current business process?
What depends on it?
An inactive Flow may be perfectly safe to remove eventually.
An old-looking Flow that's still referenced by another process is a very different situation.
Cleanup should reduce uncertainty, not create it.
3. Review Fields With Context
Unused fields seem like easy cleanup targets.
Sometimes they are.
But a field that doesn't appear on a Lightning page could still be used by:
- A Flow
- A formula
- A report
- An integration
- Apex
- A validation rule
- An API process
- Historical reporting
So I wouldn't decide a field is unused just because users don't recognize it.
I'd investigate where it's referenced and why it was created.
Descriptions help enormously here.
A field named Customer_Status_2__c with no description doesn't tell the next administrator much.
Good metadata documentation can prevent today's cleanup problem from becoming tomorrow's cleanup problem.
4. Reports and Dashboards Can Become Their Own Kind of Clutter
Reports are easy to create in Salesforce.
That's one of their strengths.
It also means organizations can accumulate a lot of them.
You might eventually find:
- Several versions of nearly the same report
- Reports created for one-time requests
- Reports owned by inactive users
- Dashboards nobody views
- Old folders that no longer match the organization
- Reports built around fields the business doesn't use anymore
I wouldn't delete reports simply because they're old.
I'd look at ownership, usage, purpose, and whether another report already serves the same need.
The goal is to make useful reporting easier to find.
5. Look for Workarounds
Some of the best clues about an org aren't in Setup.
They're in how people actually use Salesforce.
Ask users questions such as:
- What do you keep outside Salesforce?
- What information do you enter twice?
- What do you avoid updating because it's too complicated?
- What spreadsheets are still required for processes that start in Salesforce?
- Which screens have fields you don't understand?
- What do you ask another employee to fix for you?
Those answers can expose problems that a metadata inventory won't.
A technically clean org can still provide a poor user experience.
And sometimes what looks like a user-training problem is really a design problem.
6. Separate Cleanup From Redesign
This is an important distinction.
If I'm reviewing an org and find a complicated process, I don't automatically want to redesign it while I'm cleaning.
Cleanup might mean:
- Removing confirmed obsolete configuration
- Documenting what currently exists
- Correcting access
- Consolidating obvious duplicates
- Archiving unused reports
- Identifying technical debt
Redesign is different.
That may require requirements gathering, user feedback, testing, and a deliberate change to the business process.
Trying to do both simultaneously can turn a manageable cleanup effort into an uncontrolled project.
7. Document What You Decide to Keep
Cleanup isn't only about what gets removed.
It's also an opportunity to make what's left easier to understand.
If an automation is important, document its purpose.
If a field looks unusual but exists for a legitimate integration requirement, describe that.
If a permission set provides access for a specific role or responsibility, make that clear.
Good documentation reduces the chance that someone performs the exact same investigation again six months later.
I Wouldn't Try to Clean Everything at Once
A Salesforce org can contain years of configuration.
Trying to make everything perfect in one pass probably isn't realistic, and it may not even be necessary.
I'd prioritize areas based on risk and impact.
A reasonable order might be:
- Users and security
- Automation
- Data quality
- Fields and configuration
- Reports and dashboards
- Documentation
- User-experience improvements
The exact order will depend on the org.
What matters is having a method.
Cleanup Should Make the Org Easier to Understand
The goal of Salesforce cleanup isn't to achieve the smallest possible number of fields, Flows, reports, or permission sets.
It's to create an environment where the configuration that's there has a reason to be there.
You should be able to answer questions like:
What does this do?
Who needs it?
What depends on it?
Is it still supporting the business?
If nobody can answer those questions, that's where I'd start investigating.
A cleaner Salesforce org isn't just easier to administer.
It's easier to change safely.
Need help cleaning up Salesforce?
SparrowLaunch provides Salesforce administration, org cleanup, troubleshooting, and ongoing support for businesses that need help understanding and improving their Salesforce environment.