SALESFORCE CLEANUP CHECKLIST

Why this is included: Over time, Salesforce orgs accumulate technical debt in the form of unused custom fields, deprecated objects, and bloated page layouts. Each custom field consumes storage, appears in API queries, and adds complexity to data models. Unused fields on page layouts create visual clutter that slows down user adoption and increases training time. Fields created for one-off projects or pilot programs often remain in production indefinitely, creating confusion about which fields are "official" versus legacy. This accumulation degrades system performance, complicates future development, and increases the risk of data quality issues.

 

Details: Start by generating a Field Usage report from Setup > Schema Builder or use the Field Trip app from AppExchange to identify fields with zero or minimal usage over the past 90 days. Cross-reference this with page layouts to see which fields are visible to users but never populated. For custom objects, review API usage logs and report usage to determine whether the object is actively used. Page layouts should be audited for fields that are no longer relevant to current business processes—remove them from layouts even if you're not ready to delete the field itself. Record Types should be reviewed to ensure they still align with current business segmentation; consolidate or retire types that serve overlapping purposes.

 

Dos:

• Do use the Field Usage data available in Setup (requires Enterprise Edition or higher) to identify fields with low or zero population rates

• Do hide unused fields from page layouts before deleting them—this allows you to validate that no processes break

• Do document the business purpose of each custom object and field in the Description field for future reference

• Do consolidate redundant fields (e.g., three different "Customer Type" fields) into a single standardized field with proper picklist values

• Do review field-level security settings when hiding fields to ensure sensitive data isn't inadvertently exposed elsewhere

 

Don'ts:

• Don't delete custom fields without first checking for dependencies in formulas, validation rules, workflows, Process Builder, Flows, and Apex code

• Don't assume a field is unused just because it's not on a page layout—it may be populated via API or automation

• Don't create new custom objects without first checking if an existing object can be extended with record types or a lookup relationship

• Don't leave deprecated fields visible on page layouts "just in case"—this creates user confusion and data quality issues

• Don't skip reviewing Lightning Record Pages separately from Classic page layouts—they can have different field sets

Why this is included: Managed and unmanaged packages consume storage, API limits, and governor limits even when not actively used. Packages installed for proof-of-concept projects or vendor evaluations often remain in production long after the evaluation period ends. Each installed package represents a potential security risk—vulnerabilities in third-party code can expose your org to data breaches or unauthorized access. Additionally, packages may have background processes, scheduled jobs, or API callouts that continue to run and consume resources. Unused integrations tied to decommissioned systems continue to authenticate and may provide an attack vector if credentials are compromised.

 

Details: Navigate to Setup > Installed Packages to review all managed packages currently installed. For each package, confirm it is actively used by checking related custom objects, tabs, and user adoption metrics. Review the package's scheduled jobs under Setup > Scheduled Jobs and check for active Apex jobs that may be consuming resources. For integrations, review Named Credentials, Remote Site Settings, and Connected Apps to identify systems that are no longer in use. Check with application owners to confirm whether each integration is still required and properly maintained. Review the package publisher's support status—packages from vendors who no longer support the product should be prioritized for removal.

 

Dos:

• Do maintain an inventory of all installed packages with business owner, purpose, installation date, and last review date

• Do uninstall packages in a sandbox first to identify dependencies and validate that removal doesn't break critical functionality

• Do review package permissions and the objects/fields the package can access—revoke unnecessary permissions

• Do check for package updates regularly, as outdated packages may have known security vulnerabilities

• Do coordinate with business stakeholders before removing packages to ensure no hidden dependencies exist

 

Don'ts:

• Don't assume a package is unused just because users don't access its tabs—it may provide backend functionality or API services

• Don't leave evaluation or trial packages installed after the evaluation period ends

• Don't ignore packages that were installed by former administrators—document their purpose or remove them

• Don't skip reviewing the package's API usage in the API Usage dashboard—some packages make heavy API calls in the background

• Don't forget to remove associated Remote Site Settings, Named Credentials, and Custom Settings when uninstalling a package

Why this is included: Validation rules enforce data quality by preventing users from saving records that don't meet specific criteria. However, validation rules created years ago may no longer reflect current business processes, creating unnecessary friction for users. Overly restrictive validation rules force users to find workarounds (such as entering dummy data to bypass the rule), which defeats the purpose of data quality enforcement. Validation rules that fire on every record save—regardless of which fields changed—can slow down user productivity and create frustration. Additionally, validation rules that reference deprecated fields or outdated business logic can cause confusion and support tickets.

 

Details: Navigate to Setup > Object Manager and review validation rules for each major object (Lead, Account, Contact, Opportunity, Case, and key custom objects). For each rule, confirm the business requirement it enforces is still valid. Test each rule in a sandbox by attempting to save records that should trigger it—verify the error message is clear and actionable. Review the rule's formula for references to deprecated fields or outdated picklist values. Check the rule's "Active" status and "Description" field—rules without clear descriptions should be documented or removed. Use the Setup Audit Trail to identify when each rule was last modified and by whom.

 

Dos:

• Do review validation rules at least annually to ensure they still reflect current business requirements

• Do write clear, user-friendly error messages that explain what the user needs to fix and why

• Do use formula fields or Flow to provide warnings instead of hard stops where appropriate

• Do test validation rules with real users to ensure they don't create excessive friction in common workflows

• Do document the business justification for each validation rule in the Description field

 

Don'ts:

• Don't create validation rules that fire on every save when they only need to check specific field changes—use ISCHANGED() or PRIORVALUE() functions

• Don't write cryptic error messages like "Error: Rule violated"—explain what field is wrong and what value is expected

• Don't leave inactive validation rules in the org indefinitely—delete them if they're no longer needed

• Don't create overlapping validation rules that check the same condition—consolidate them into a single rule

• Don't forget to review validation rules when business processes change (e.g., new sales stages, updated compliance requirements)

Why this is included: Email templates are often created for specific campaigns, projects, or business processes and then forgotten. Outdated templates may contain incorrect branding, deprecated product names, broken links, or references to employees who no longer work at the company. Users who accidentally select the wrong template can send unprofessional or confusing communications to customers and prospects. Unused templates clutter the template picker, making it harder for users to find the correct template. Additionally, templates that reference merge fields from deprecated custom fields will fail to render properly, creating a poor user experience.

 

Details: Navigate to Setup > Email Templates (Classic) or App Launcher > Email Templates (Lightning) to review all templates. For each template, check the "Last Used Date" (if available) or review email logs to identify templates that haven't been used in the past 180 days. Test each active template by sending a preview email to yourself—verify that merge fields populate correctly, links work, and branding is current. Review templates for references to deprecated fields, old product names, or former employees. Organize templates into folders by department or use case to make them easier to find. Deactivate or delete templates that are no longer relevant, and archive those needed for historical reference but shouldn't be used going forward.

 

Dos:

• Do organize email templates into clearly labeled folders (Sales, Support, Marketing, HR) to improve discoverability

• Do include the template's purpose and intended audience in the Description field

• Do test templates regularly to ensure merge fields, links, and formatting render correctly

• Do establish a template review schedule (e.g., quarterly) to catch outdated content before it's used

• Do create a naming convention for templates that includes the department, purpose, and version (e.g., "Sales_Welcome_Email_v2")

 

Don'ts:

• Don't leave templates active that reference deprecated merge fields—they will fail to render and confuse users

• Don't allow users to create personal templates without governance—establish a process for template creation and approval

• Don't forget to update templates when branding, product names, or contact information changes

• Don't leave templates with broken links or outdated legal disclaimers active

• Don't skip reviewing HTML email templates for accessibility issues (alt text for images, proper heading structure)