SALESFORCE CLEANUP CHECKLIST

Why this is included: Unused or redundant automations create technical debt, slow down system performance, and increase maintenance complexity. They can also cause unexpected behavior when interacting with newer automations or evolving data patterns.

 

Details: Conduct a comprehensive audit of all automation tools in your Salesforce org. Identify Flows, Apex triggers, and Process Builder processes that are no longer actively used or have been superseded by newer implementations. Document the purpose and usage frequency of each automation before making retirement decisions.

 

Dos:

• Export a complete inventory of all automations with their last modified dates and active status.

• Analyze automation usage through debug and execution logs over the past 90 days.

• Communicate retirement plans with stakeholders before making changes.

• Document the business purpose of each automation before retiring it.

• Archive code and configuration details for future reference.

• Deactivate automations first and monitor for 2-4 weeks before permanent deletion.

 

Don'ts:

• Don't delete automations without first deactivating and monitoring them.

• Don't assume an automation is unused just because it's old.

• Don't retire automations during peak business periods or major releases.

• Don't skip documenting why an automation was retired.

• Don't forget to check for dependencies in other systems or integrations.

Why this is included: Business processes evolve continuously, but automations often remain static. Misaligned automations can enforce outdated workflows, frustrate users, and reduce platform adoption.

 

Details: Interview current users and stakeholders to understand their actual workflows. Compare existing automation logic against real-world business processes to identify gaps where automation no longer supports current needs or actively hinders efficient work.

 

Dos:

• Conduct working sessions with end users to walk through daily workflows.

• Compare automation logic to current process documentation.

• Identify user workarounds and the underlying pain points driving them.

• Update automations to reflect current organizational structure and processes.

• Prioritize changes based on impact and business value.

• Establish a feedback loop for continuous alignment.

 

Don'ts:

• Don't rely solely on documentation from previous years.

• Don't assume technical stakeholders fully understand current business needs.

• Don't make changes without validating with end users.

• Don't deploy updates without proper sandbox testing.

• Don't ignore recurring user complaints about "the system making them do extra work."

Why this is included: Salesforce releases three times per year, and your org's data patterns and integrations evolve constantly. Automations that worked perfectly six months ago may fail or behave unexpectedly due to dependency changes, new field validations, or updated API versions.

 

Details: Identify mission-critical automations affecting revenue, compliance, or customer experience. Develop comprehensive test scenarios covering edge cases, bulk operations, and integration points. Test against recent Salesforce releases and any changes to connected systems in lower environments before deploying to Production.

 

Dos:

• Create a test matrix covering normal, edge, and error scenarios.

• Test with bulk data loads (200+ records) to identify governor limit issues.

• Verify behavior with null values, special characters, and boundary conditions.

• Test integration points with external systems after any API changes.

• Document test results and maintain regression test suites.

• Schedule regular testing cycles (quarterly minimum).

 

Don'ts:

• Don't test only the "happy path" scenarios.

• Don't skip testing after Salesforce seasonal releases.

• Don't test only in production or only with single-record operations.

• Don't ignore warning messages or debug log errors.

• Don't assume automations work correctly just because they're not throwing errors.

Why this is included: Approval processes directly impact business velocity and decision-making. Outdated approval paths create bottlenecks, route requests to wrong people, and can result in compliance issues or poor customer experiences.

 

Details: Audit all active approval processes to ensure they reflect current organizational structure, business rules, and compliance requirements. Validate approval criteria, routing logic, and notification mechanisms.

 

Dos:

• Document all active approval processes and their business purposes

• Map current approval paths against organizational charts

• Review approval criteria for relevance to current business rules

• Test approval routing with real-world scenarios

• Verify that approval history is being properly maintained

• Ensure approval processes comply with current audit requirements

 

Don'ts:

• Don't leave approval processes pointing to inactive users or old roles

• Don't maintain approval steps that no longer serve a business purpose

• Don't forget to update approval processes when org structure changes

• Don't skip testing the full approval chain from submission to final approval

• Don't ignore feedback from users about approval delays or confusion

Why this is included: Outdated approval paths cause delays, route requests to inappropriate approvers, and can result in decisions being made by people without proper authority or context.

 

Details: Review entry criteria, approval steps, and routing rules for each approval process. Remove obsolete criteria based on deprecated fields or old business rules. Update approval paths to reflect current decision-making authority.

 

Dos:

• Identify approval processes with criteria referencing deprecated or unused fields

• Update dollar thresholds and other numeric criteria to reflect current policies

• Simplify approval paths where possible to reduce cycle time

• Remove approval steps that are routinely rubber-stamped

• Update criteria to use current picklist values and record types

• Document the rationale for each approval criterion

 

Don'ts:

• Don't remove approval steps without confirming with compliance/legal teams

• Don't update criteria without testing against historical data patterns

• Don't create overly complex criteria that are difficult to maintain

• Don't forget to update related documentation and training materials

• Don't change approval criteria during active approval cycles

Why this is included: Organizational changes happen frequently, but approval processes often aren't updated accordingly. This results in requests being routed to people who have changed roles, left the company, or no longer have appropriate authority.

 

Details: Cross-reference all approver assignments (users, roles, queues) against current organizational structure. Identify and fix assignments pointing to inactive users, outdated roles, or restructured departments.

 

Dos:

• Generate a report of all approvers referenced in approval processes

• Verify each approver is still active and in the appropriate role

• Update role-based approvals to reflect current role hierarchy

• Set up delegated approvers for key personnel

• Implement queue-based approvals for team-level decisions where appropriate

• Create alerts for approval processes with inactive approvers

 

Don'ts:

• Don't hard-code specific users as approvers unless absolutely necessary

• Don't forget to update backup/delegated approvers

• Don't leave approval processes pointing to generic admin accounts

• Don't assume role-based approvals are still correct after org restructures

• Don't skip validation of manager hierarchy for dynamic approver assignments

Why this is included: Approval processes often trigger email notifications and field updates that may no longer be necessary or accurate. Irrelevant emails reduce engagement, and outdated field updates can corrupt data or break downstream processes.

 

Details: Review all email alerts and field updates configured within approval processes. Verify that email templates contain current information, are sent to the appropriate recipients, and serve a clear business purpose. Ensure field updates reflect current data model and business logic.

 

Dos:

• Test email alerts to verify they're being delivered and are readable

• Review email template content for accuracy and relevance

• Verify field updates don't conflict with other automations

• Confirm field updates use current picklist values and data types

• Check that email recipients still need the notifications

• Update email templates to reflect current branding and messaging

 

Don'ts:

• Don't send redundant notifications that duplicate other system alerts

• Don't update fields that are managed by other automations

• Don't use outdated email templates with old branding or contact information

• Don't forget to test email alerts in sandbox before deploying

• Don't send approval notifications to distribution lists that aren't monitored

Why this is included: When multiple automations update the same fields, they can create race conditions, infinite loops, or unpredictable behavior. This leads to data quality issues, performance problems, and difficult-to-debug errors.

 

Details: Map all field updates across Flows, Process Builder, Workflow Rules, and Apex triggers. Identify fields modified by multiple automations and analyze the order of execution and potential conflicts.

 

Dos:

• Create a field-level dependency matrix showing which automations touch which fields

• Document the order of execution for automations affecting the same records

• Consolidate redundant field updates into a single automation where possible

• Implement proper recursion prevention in Apex triggers

• Use Flow orchestration to coordinate multiple automation steps

• Add debug logging to track field value changes through automation chains

 

Don'ts:

• Don't have multiple automations updating the same field with different logic

• Don't create circular dependencies between automations

• Don't ignore recursion warnings in debug logs

• Don't mix automation tools (Flow, Process Builder, Workflow) for the same business process

• Don't forget to consider validation rules and required fields in automation sequences

Why this is included: A poor deployment strategy leads to production incidents, failed deployments, and difficulty rolling back changes. Following best practices ensures reliable, repeatable deployments with minimal risk.

 

Details: Evaluate your current deployment process against Salesforce recommended practices. Ensure you have a defined sandbox strategy, structured deployment tooling (change sets, Metadata API usage, or DevOps tools), and validation procedures.

 

Dos:

• Use a dedicated Developer Pro or Partial Copy sandbox for development

• Create a Full Copy sandbox for SIT and UAT prior to production deployment

• Use change sets, SFDX, or a DevOps tool for structured deployments

• Run all test classes and achieve minimum 75% code coverage before deployment

• Create deployment runbooks documenting steps and rollback procedures

• Schedule deployments during maintenance windows with stakeholder notification

• Validate deployments in production before making changes live

 

Don'ts:

• Don't develop directly in production

• Don't deploy during business hours without approval

• Don't skip testing in a sandbox environment

• Don't deploy without a rollback plan

• Don't ignore deployment warnings or test failures

• Don't deploy large changes without breaking them into smaller releases

Why this is included: Without proper version control, you lose the ability to track who made what changes, when, and why. This creates compliance risks, makes troubleshooting difficult, and prevents effective collaboration among team members.

 

Details: Assess your current version control practices for Salesforce metadata. Ensure all configuration and code changes are tracked in a version control system with an appropriate branching strategy and clear commit practices.

 

Dos:

• Use Git or another version control system for all Salesforce metadata

• Implement a branching strategy (e.g., GitFlow) appropriate for your team size

• Require meaningful commit messages that explain the "why" of changes

• Set up code review processes before merging to main branches

• Tag releases and maintain a changelog

• Integrate version control with your CI/CD pipeline

• Store version control history for audit and compliance purposes

 

Don'ts:

• Don't rely solely on Salesforce's built-in change tracking

• Don't commit directly to production branches without review

• Don't use vague commit messages like "updates" or "fixes"

• Don't skip version control for "small" configuration changes

• Don't forget to version control test classes and test data

• Don't allow untracked changes to accumulate before committing

• Don't ignore merge conflicts or resolve them without understanding the impact