How to Clean Up a Salesforce Org Without Breaking What Works

Salesforce cleanup is not the same as deleting everything that looks old. In an inherited org, unused fields, automation, reports, permissions, and record values may still support integrations, historical reporting, seasonal processes, or undocumented handoffs.

A safe cleanup starts with evidence, dependencies, backups, and a clear definition of what “better” should mean. The target is not a perfect-looking Setup menu. The target is a Salesforce org people can trust, maintain, and change without surprises.

Define the cleanup objective

Start with the problem you are trying to solve. “Clean up Salesforce” is too broad to guide safe work.

• Are users confused by too many fields or page layouts?
• Are dashboards hard to trust because data quality is poor?
• Are inactive users, stale owners, or license assignments creating noise?
• Are automations overlapping or failing silently?
• Are integrations writing values nobody owns?

Define the outcome first. A cleanup for adoption may focus on page layouts and required fields. A cleanup for reporting trust may focus on picklists, owners, lifecycle dates, duplicate rules, and dashboard dependencies.

Capture a baseline

Before bulk edits, capture enough evidence to roll back or explain the change later.

• Export the records or metadata you plan to change.
• Save screenshots or notes for important settings if the team uses UI review.
• List affected objects, fields, record types, automation, reports, dashboards, integrations, and owners.
• Record who approved the cleanup and what success should look like.

For sensitive cleanup, use a sandbox or a small controlled production scope. Do not make broad deletes because a report says something has low usage.

Review users and licenses

User cleanup is often the safest place to start because inactive users, stale roles, and old license assignments create visible admin drag.

• Review inactive users, frozen users, integration users, and community or portal users.
• Confirm whether deactivation affects ownership, queues, scheduled jobs, dashboards, report subscriptions, or integrations.
• Document exceptions where a user must stay active for an integration or scheduled process.

Related example: inactive user cleanup dashboard.

Review profiles, permission sets, and access

Access cleanup needs more care than a simple profile count. Profiles, permission sets, permission set groups, roles, public groups, queues, sharing rules, and manual shares can all affect who sees and changes data.

• Look for old permission sets with no clear owner.
• Check permission set groups and muting permission sets before removing individual access.
• Review roles, public groups, queues, and sharing rules tied to approvals, assignment, reports, or integrations.
• Confirm access changes with real user examples, not just setup screenshots.

Do not remove access just because it looks broad. First confirm who uses it, what process it supports, and what breaks if it changes.

Inventory automation

Automation cleanup should follow an audit. Include Flow, Apex, approval processes, validation rules, duplicate rules, assignment rules, escalation rules, Workflow Rules, Process Builder, scheduled jobs, and managed-package automation.

Legacy automation may still execute in a current org. Treat Workflow Rules and Process Builder as migration candidates, not automatic deletion candidates.

For a deeper process, use the Salesforce automation audit checklist.

Review fields and record types

Field cleanup is where admins can do real damage if they move too fast. A field that looks unused may still appear in a formula, Flow, validation rule, Apex class, integration mapping, report, dashboard, page layout, list view, email template, or historical analysis.

• Identify fields with low population, unclear labels, duplicate meanings, or no owner.
• Check field dependencies, formulas, validation rules, automation, Apex references, report usage, and integration mappings.
• Use “Do Not Use” labels, help text, page-layout removal, or field-level security changes before deletion when risk is unclear.
• Review record types with page layouts, picklist values, business processes, profiles, automations, and reports before consolidation.

For field-specific cleanup, see Archive Fields in Salesforce Safely.

Review reports and dashboards

Reports and dashboards are easy to clutter and easy to break. Do not delete a report only because it has an old last-run date. It may support a quarterly board review, an audit, a dashboard component, or a team that exports data manually.

• Group reports by folder, owner, business process, dashboard dependency, and subscription.
• Find duplicates and stale variants, then confirm which version the business trusts.
• Check dashboard source reports before archiving anything.
• Move uncertain reports into an archive folder before deletion.

For dashboard trust, see how to create Salesforce dashboards that drive action.

Review data-quality exceptions

Data cleanup should focus on the records that create operational risk.

• Duplicate Leads, Contacts, Accounts, or custom-object records.
• Picklist values that mean the same thing or no longer match the business.
• Missing owners, stale owners, inactive-user ownership, and unassigned queues.
• Missing required lifecycle dates, source fields, close reasons, or division/territory values.
• Records stuck in old statuses that still affect reporting.

Use duplicate rules, matching rules, validation rules, required fields, and controlled update jobs carefully. The rule should support the process, not punish users for historical data problems they did not create.

Review integrations and managed packages

Integrations can make “unused” metadata risky. Before removing fields, values, users, or automation, check API users, middleware jobs, managed packages, web forms, imports, exports, and downstream reporting tools.

• Look for API dependencies and scheduled jobs.
• Check whether external systems still send or expect a field value.
• Review managed-package documentation before changing package-owned metadata.
• Coordinate with the system owner before disabling an integration user or mapping.

Separate safe cleanup from risky cleanup

Some cleanup is usually low risk: clearer descriptions, report-folder naming, page-layout organization, obsolete list views, and documented ownership. Other cleanup needs dependency review and testing first.

Back up before bulk changes

Before bulk data updates or metadata removal, back up the affected data and record the current configuration. For larger work, include a rollback plan and a point of contact who can approve stopping the change if verification fails.

Backups are not just for emergencies. They help explain what changed when a stakeholder asks why an old report looks different.

Test in a sandbox or controlled scope

Sandbox testing is best when cleanup touches automation, access, integrations, reports, or schema. If sandbox parity is poor, use a tightly controlled production scope and document the limit.

• Test with realistic profiles, permission sets, record types, ownership paths, and data conditions.
• Verify dashboards and reports after the change.
• Review automation and integration side effects.
• Get business-owner signoff before expanding the cleanup.

Verify runtime behavior

Setup review tells you what should happen. Runtime verification tells you what actually happens. After a cleanup change, create or update sample records, run the affected reports, check dashboards, review Flow interviews or logs, and confirm that users can still complete the process.

If the change affects reporting trust, compare before-and-after numbers with the business owner instead of assuming the lower number is cleaner.

Document what changed

Every cleanup pass should leave a short record of what changed, why it changed, who approved it, how it was verified, and what should be checked again later. This is the difference between cleanup and another undocumented admin project.

Build a recurring maintenance cadence

Org cleanup works best as a cadence, not a rescue mission. A useful rhythm is small monthly checks, quarterly targeted cleanup, and annual deeper review of automation, access, reporting, and integrations.

If your org already has years of field, report, automation, and access debt, start with one high-value area and make it measurable. My Salesforce cleanup services focus on that kind of controlled, documented change.

Salesforce cleanup checklist