SALESFORCE CLEANUP CHECKLIST

Why this is included: Over time, Salesforce orgs accumulate hundreds or thousands of reports and dashboards created for one-time analyses, completed projects, or departed team members. These unused assets clutter the report list, make it difficult for users to find relevant reports, consume storage and processing resources, and can cause confusion when users accidentally reference outdated metrics. A bloated reports library reduces user productivity and creates the false impression that certain metrics are still being actively monitored when they aren't. Regular archiving ensures that only current, relevant reports remain visible and accessible to users.

 

Details: Navigate to Setup > Reports and Dashboards Settings to review report usage metrics. Generate a report on the Report object itself to identify reports that haven't been run in the past 90–180 days. Cross-reference this list with business stakeholders to confirm which reports are truly obsolete versus seasonally used (such as year-end or quarterly reports). For reports that are confirmed as unused, move them to an "Archived Reports" folder with restricted access rather than deleting them immediately—this preserves the report definition in case it's needed for historical reference or compliance. For dashboards, check the "View Dashboard" audit trail to identify dashboards that haven't been viewed in months. Before archiving a dashboard, verify that it is not embedded in a Lightning page or referenced in documentation that users might still follow.

 

Dos:

• Do create a dedicated "Archived Reports" and "Archived Dashboards" folder structure with read-only access for admins

• Do run a usage analysis covering at least 90 days to identify truly unused reports vs. seasonally-used ones

• Do communicate with report owners and frequent users before archiving to confirm the reports are no longer needed

• Do export report definitions before archiving in case you need to reference the logic later

• Do document why each report was archived (e.g., "Project completed," "Owner departed," "Superseded by new dashboard")

• Do schedule this cleanup quarterly to prevent accumulation

 

Don'ts:

• Don't delete reports immediately—archive them first and wait 30-60 days to confirm no one needs them

• Don't archive reports during peak business periods (quarter-end, year-end) when users may suddenly need historical reports

• Don't assume a report is unused just because it has low run counts—it may be scheduled or embedded elsewhere

• Don't forget to check if reports are used as data sources for dashboards before archiving

• Don't overlook reports in private folders—work with users to clean up their personal report collections

• Don't archive reports that are required for compliance, audits, or regulatory reporting without confirming retention requirements

Why this is included: Executive dashboards and quarterly planning reports are critical decision-making tools that inform resource allocation, strategic planning, and performance management. When these dashboards display incorrect data due to outdated filters, deprecated fields, or broken report sources, leaders may make decisions based on flawed information, resulting in misallocated resources, missed opportunities, or strategic missteps. Unlike operational reports that are used daily (where errors are quickly caught), executive dashboards may only be reviewed monthly or quarterly, meaning errors can go undetected for extended periods. This item ensures that your organization's most important metrics are accurate, current, and aligned with how leadership actually evaluates business performance today.

 

Details: Identify all dashboards used by leadership, executive team members, and for quarterly business reviews (QBRs). For each dashboard, validate that the underlying reports are still pulling from the correct objects and fields, that filters reflect current business definitions (such as updated fiscal year dates, territory assignments, or product categories), and that calculated metrics match how the business currently defines success. Review dashboard components for broken report references, filters that reference deprecated picklist values, or groupings based on fields that are no longer maintained. Schedule time with dashboard stakeholders to walk through each component and confirm it still provides the insights they need. Update dashboard refresh schedules if needed—executive dashboards often benefit from real-time or hourly refresh rather than daily.

 

Dos:

• Do schedule quarterly validation sessions with executive stakeholders to review dashboard accuracy and relevance

• Do verify that date filters align with your organization's current fiscal calendar

• Do test dashboard performance—executive dashboards should load quickly and refresh reliably

• Do ensure dashboard components use consistent metric definitions (e.g., "pipeline" means the same thing across all components)

• Do document the business logic behind each dashboard component so future admins understand what it's measuring

• Do set up dashboard subscriptions or alerts so leadership is notified of key metric changes without having to log in

 

Don'ts:

• Don't assume executive dashboards are correct just because no one has complained—leaders often don't have time to validate data quality themselves

• Don't use dashboard filters that reference fields users no longer maintain (e.g., filtering by a "Region" field that's been replaced)

• Don't create dashboards with more than 15-20 components—they become slow to load and difficult to interpret

• Don't forget to update year-over-year comparison reports after fiscal year changes

• Don't rely on manual data entry for key metrics shown on executive dashboards—automate wherever possible to reduce human error

• Don't mix different data timeframes on the same dashboard without clearly labeling them (e.g., one component showing "last 30 days" and another showing "current quarter")

Why this is included: Business definitions evolve constantly—sales stages get renamed, territories get restructured, product lines get consolidated, and what counts as a "qualified lead" changes based on market conditions. When reports continue using outdated filters, field references, or formulas, they produce metrics that no longer align with how the business operates, leading to confusion, misaligned KPIs, and poor decision-making. A report showing "Q1 pipeline" that still filters on the old fiscal calendar, or a "win rate" calculation that includes stages that are no longer used, creates the illusion of insight while actually misleading stakeholders. This item ensures that your reporting infrastructure reflects current business reality, not historical definitions that may have been accurate two years ago but are now obsolete.

 

Details: For each key report, review filter criteria line by line to confirm that picklist values, date ranges, record types, and field values match current business definitions. Check custom report formulas to ensure they reference active fields and use calculation logic that aligns with how the business currently defines metrics (for example, if your sales team changed how they calculate "weighted pipeline," your reports should reflect that change). Review bucket fields and groupings to confirm categories are still relevant—for example, groupings by region should reflect current territory assignments, not old ones. Validate that cross-object filters (such as "Opportunities where Account.Industry = X") still work correctly and that relationship fields haven't been changed or removed. If you discover reports using outdated definitions, update them and communicate the change to users so they understand why historical comparisons may show discontinuities.

 

Dos:

• Do maintain a data dictionary that documents current business definitions for key metrics like pipeline, revenue recognition, and qualified leads

• Do involve business stakeholders (sales ops, marketing ops, finance) in reviewing report logic to confirm it matches their current processes

• Do version control report definitions when making significant changes, so you can reference historical logic if needed

• Do add report descriptions explaining the business logic, especially for complex formulas

• Do update bucket field categories when business segmentation changes (e.g., product categories, deal sizes)

• Do test reports against known data sets to confirm they produce expected results after business definition changes

 

Don'ts:

• Don't assume report formulas are correct just because they've been in place for years—business logic evolves

• Don't use hard-coded date filters (e.g., "1/1/2024 to 12/31/2024")—use relative date filters like "Current FY" that update automatically

• Don't filter on picklist values that have been deactivated or replaced without updating the report criteria

• Don't create overly complex formulas that are difficult for future admins to understand and maintain

• Don't reference fields in formulas that are no longer consistently populated—this creates gaps in reporting

• Don't forget to check row-level formulas in addition to summary formulas, as both can become outdated

Why this is included: Report and dashboard folders control who can view, edit, and run reports—making folder permissions a critical component of data security and governance. Over time, folder sharing settings often become misaligned with actual team structures as employees change roles, departments are reorganized, or new teams are created. When folder permissions are too restrictive, users can't access the reports they need to do their jobs, leading to duplicated effort as they recreate reports that already exist but are hidden from them. Conversely, when folder permissions are too permissive, users may access sensitive data they shouldn't see (such as compensation information, executive pipeline data, or customer PII), creating compliance and security risks. This item ensures that report visibility aligns with current organizational structure and the principle of least-privilege access.

 

Details: Review the sharing settings on all report and dashboard folders by navigating to the Reports tab and checking folder properties. For each folder, confirm that the users, roles, and public groups with access still align with who should be able to view that data today. Pay particular attention to folders containing sensitive reports (such as those showing individual rep performance, executive compensation, or customer-specific data) and ensure they're restricted to appropriate audiences. Check for "Public" folders that may have been created for convenience but now expose data too broadly. Review folder access for departed employees—while Salesforce automatically removes individual user access when someone is deactivated, public group and role-based sharing may persist if those assignments weren't updated during offboarding. Consider implementing a folder structure that mirrors your organizational hierarchy (e.g., "Sales - AMER," "Sales - EMEA," "Finance," "Executive") to make access control more intuitive and maintainable.

 

Dos:

• Do use public groups and roles for folder sharing rather than individual user assignments—this scales better as your org grows

• Do implement a clear folder naming convention that makes it obvious what data is in each folder (e.g., "Exec - Board Reports," "Sales - Pipeline Reports")

• Do review folder permissions quarterly, especially after organizational changes

• Do restrict edit access to folders containing key operational reports—users can still create personal copies if they need customization

• Do document folder access policies in your Salesforce governance documentation

• Do create separate folders for reports in development/testing vs. production-ready reports that teams rely on

 

Don'ts:

• Don't grant "View All Data" permission to users just to solve folder access issues—use targeted folder sharing instead

• Don't create too many folders—this makes reports harder to find and folder permissions harder to manage

• Don't share sensitive report folders with "All Internal Users" or overly broad public groups

• Don't forget to remove folder access for public groups when teams are dissolved or restructured

• Don't rely solely on row-level security to protect sensitive data—folder permissions provide an additional layer of control

• Don't allow users to create reports in public folders without review—this can lead to inconsistent or incorrect reports being used across the organization

Why this is included: When fields are removed, automations are retired, or integrations are decommissioned, reports that depend on those elements do not fail immediately—they instead return incomplete data, often in ways that aren't obvious to end users. A report filtering on a field that's no longer being populated will silently exclude records, creating the false impression that activity has decreased. A report that depends on a field updated by a retired automation will show stale data without any error message. These "broken but not obviously broken" reports are particularly dangerous because they continue to inform business decisions while providing increasingly inaccurate information. This item ensures that changes to your data model and automation layer are reflected in your reporting infrastructure, preventing hidden data quality issues from undermining decision-making.

 

Details: When planning to deprecate a field, retire an automation, or decommission an integration, first identify all reports and dashboards that reference those elements. Salesforce provides a "Where is this used?" reference tool for fields, but it doesn't catch all report dependencies, especially formulas that reference fields indirectly. Manually search report definitions for field API names, and use a metadata extraction tool if your report library is large. For each affected report, determine whether it should be updated to use a replacement field, retired because it's no longer needed, or flagged as "broken" with a plan to fix it. After making changes to fields or automations, run affected reports and compare results to historical data to confirm they're still producing expected outputs. Create a change management process that requires report impact assessment before any field, automation, or integration changes are deployed to production.

 

Dos:

• Do use Salesforce's field dependency viewer and metadata API to identify reports referencing fields before deprecating them

• Do search report formulas for field API names, not just field labels, since formulas use API names

• Do test reports after making field or automation changes to confirm they still produce correct results

• Do communicate report changes to end users, especially if a report's definition has changed significantly

• Do create a temporary "Reports Under Review" folder for reports affected by field deprecation while you evaluate whether to update or retire them

• Do document field dependencies for key reports so future admins know which reports will break if certain fields are removed

 

Don'ts:

• Don't deprecate fields without first checking report dependencies—hidden breakage is worse than obvious errors

• Don't assume reports will throw an error if a field they reference is removed—they'll often just return incomplete results

• Don't forget to check dashboard filters in addition to report filters—dashboards can apply additional filtering on top of underlying reports

• Don't remove fields that are only used in reports without first confirming the reports can be retired or updated

• Don't overlook historical trend reports—they may depend on fields that were deprecated years ago but are still needed for year-over-year comparisons

• Don't deploy field or automation changes to production without testing affected reports in a sandbox first