SALESFORCE CLEANUP CHECKLIST

Why this is included: Salesforce orgs are complex, living systems that evolve continuously through customizations, integrations, and process changes. Without centralized, up-to-date documentation, institutional knowledge resides with a small number of long-tenured admins or developers, creating significant risk when those individuals leave, change roles, or are unavailable. New team members struggle to understand why things were built a certain way, troubleshooting becomes time-consuming guesswork, and technical debt accumulates because no one dares to change something they don't fully understand. Current-state documentation provides a single source of truth for how your org works today, enabling faster onboarding, more confident troubleshooting, better change management, and reduced dependency on tribal knowledge. It also serves as a baseline for future architecture planning and a reference point for compliance audits.

 

Details: Create a centralized documentation repository (such as a Confluence space, SharePoint site, or even a Salesforce Knowledge base within your org) that captures the current state of your Salesforce implementation. At minimum, document the following: key automations (Flows, Process Builder, Apex triggers) with descriptions of what they do and why they were built; approval processes with routing logic and business justification; major integrations showing data flow, authentication method, and which teams own each integration; custom objects and fields with clearly defined business meanings; critical reports and dashboards with explanations of metrics; and a "known issues and technical debt" list itemizing problems you're aware of but haven't yet fixed. Update this documentation whenever significant changes are made, and assign ownership of each documentation section to specific team members to ensure it doesn't become outdated.

 

Dos:

• Do create a centralized, easily accessible documentation repository that all admins and developers can access

• Do assign ownership of each documentation section to a specific person or team

• Do include "why" in your documentation, not just "what"—explain the business context behind technical decisions

• Do document workarounds and known issues so future team members don't waste time rediscovering them

• Do include architecture diagrams showing how your major systems integrate

• Do version control your documentation so you can reference how things worked at specific points in time

• Do review and update documentation quarterly to keep it current

 

Don'ts:

• Don't rely solely on Salesforce's native Setup Audit Trail as documentation—it shows what changed but not why

• Don't create documentation that's so detailed it becomes a maintenance burden and quickly falls out of date

• Don't store critical documentation only in one person's personal notes or local files

• Don't document only what you built—also document what you decided not to build and why

• Don't skip documenting "temporary" workarounds—they often become permanent and need to be understood by future admins

• Don't create documentation without an assigned owner—unowned documentation becomes obsolete quickly

Why this is included: Automations, approvals, and integrations are the "plumbing" of your org—they're often invisible to end users but critical to how the business operates. When these systems are undocumented, troubleshooting failures becomes a time-consuming archaeological exercise of reading code, examining debug logs, and interviewing users to piece together what's supposed to happen. Integrations are particularly high-risk because they span multiple systems, and a failure in Salesforce's integration with an ERP or marketing platform can have cascading impacts across the business. Comprehensive documentation of these systems enables faster incident response, reduces onboarding time for new technical team members, and provides visibility into complex dependencies that might not be obvious from looking at the configuration alone.

 

Details: For each active automation (Flow, Process Builder, Apex trigger), document: the business process it supports, the object(s) it acts on, the triggering event, the actions it performs, any dependencies on other automations or integrations, and the business owner who can make decisions about changes. For approval processes, document the approval path, routing rules, decision criteria, and how approvals integrate with downstream systems. For integrations, document the external system name, authentication method, data flow direction (inbound, outbound, or bidirectional), sync frequency, which Salesforce objects are involved, error handling procedures, and technical and business owners. Include integration architecture diagrams that show how data flows between systems and where transformations occur (e.g., in middleware).

 

Dos:

• Do create a visual map of automation dependencies showing which automations trigger other automations

• Do document the order of execution for automations acting on the same object

• Do maintain a list of all active integrations with their sync schedules and data volumes

• Do include example scenarios in your automation documentation (e.g., "When a user does X, the system does Y")

• Do document what happens when an integration fails—how errors are logged and who gets notified

• Do capture both technical details (for developers) and business explanations (for process owners)

 

Don'ts:

• Don't assume code comments are sufficient documentation—they're not accessible to non-developers

• Don't document only successful paths—also document error handling and edge cases

• Don't overlook scheduled automations and batch jobs—they're easy to forget about because they run in the background

• Don't forget to document testing procedures for critical automations

• Don't skip documenting integrations that "just work"—they're often the highest risk because no one looks at them until they break

• Don't create separate documentation for each automation in isolation—show how they work together as a system

Why this is included: Every org has technical debt—shortcuts taken to meet deadlines, workarounds implemented to avoid complex refactoring, deprecated features still in use because migration is time-consuming, or integrations held together with duct tape because "we'll replace that system next year." When technical debt isn't explicitly tracked and prioritized, it accumulates silently until it causes a production incident, blocks an important project, or becomes so entrenched that addressing it would require a full org rebuild. A maintained technical debt list makes these issues visible to leadership, enables informed prioritization decisions, and ensures that teams aren't surprised by problems they should have been aware of. It also provides valuable context for new team members about why certain parts of the org are structured in non-obvious ways.

 

Details: Create and maintain a centralized list of known issues, workarounds, and technical debt items in your org. For each item, document: a clear description of the problem, the business impact (how does this affect users or business processes?), a risk rating (low/medium/high), when the issue was identified, any temporary workarounds in place, the estimated effort to fix, and the long-term plan for resolution. Update this list quarterly, reprioritize items based on changing business needs and available resources. Share this list with leadership during planning cycles so technical debt can be weighed against new feature development. When items are resolved, move them to a "Resolved" section rather than deleting them, creating a record of continuous improvement.

 

Dos:

• Do quantify the business impact of technical debt items (e.g., "costs 5 hours per week in manual workarounds," "blocks planned integration with System X")

• Do prioritize technical debt using a risk/effort matrix—tackle high-risk, low-effort items first

• Do include technical debt in your roadmap and sprint planning, not just new features

• Do communicate technical debt to business stakeholders in business terms, not technical jargon

• Do celebrate when technical debt is paid down—it's often invisible work that deserves recognition

• Do track how long items have been on the technical debt list to identify problems that keep getting deprioritized

 

Don'ts:

• Don't treat technical debt as something to be hidden—transparency enables better planning

• Don't let the technical debt list become a dumping ground for every minor issue—focus on items with meaningful impact

• Don't create a technical debt list and then never revisit it—it should be a living document

• Don't assume technical debt will "fix itself" or become irrelevant—it usually gets worse over time

• Don't skip documenting workarounds even if they're embarrassing—future admins need to know about them

• Don't address technical debt without first documenting what you're changing and why—you might need to reference that decision later

Why this is included: Salesforce governance without clear ownership is governance in name only. When no one is explicitly responsible for maintaining data standards, approving new customizations, or monitoring org health, these tasks fall through the cracks, leading to data quality degradation, uncontrolled customization sprawl, and inconsistent user experiences. Conversely, when ownership is clearly defined and communicated, there's accountability for outcomes, decision-making is faster and more consistent, and teams know who to engage when they have questions or need approvals. This item establishes explicit ownership for the ongoing governance activities that keep your org healthy, secure, and aligned with business needs over time, moving from reactive firefighting to proactive management.

 

Details: Identify and document specific owners (individuals or teams) for each major governance area: data quality standards and cleanup (who defines what "clean data" means and enforces it?), field and object creation (who reviews and approves requests for new custom fields and objects?), automation and approval process changes (who ensures new automations don't conflict with existing logic?), integration governance (who approves new integrations and monitors existing ones?), security and access control (who reviews user permissions and folder sharing?), and reporting standards (who ensures reports use consistent definitions?). For each area, define not just who is responsible, but also what their decision-making authority is, how requests are submitted, expected turnaround times, and escalation paths for disputes. Communicate these ownership assignments org-wide so everyone knows who to contact.

 

Dos:

• Do create a RACI matrix (Responsible, Accountable, Consulted, Informed) for key governance decisions

• Do assign ownership to specific individuals or teams with named backup owners

• Do communicate governance owners through a centralized contact list or Salesforce Community page

• Do empower owners with appropriate Salesforce permissions and access to make decisions

• Do define clear criteria for decision-making so ownership doesn't become a bottleneck

• Do review ownership assignments annually to ensure they still reflect current team structure

 

Don'ts:

• Don't assign ownership to generic roles like "admin team" without naming specific people

• Don't create ownership assignments that are so distributed no one can make decisions quickly

• Don't fail to communicate ownership—users should know who to contact for each type of request

• Don't assign ownership without also assigning time and resources to fulfill those responsibilities

• Don't create governance processes that are so heavyweight they encourage people to work around them

• Don't leave ownership assignments unchanged after organizational restructuring

Why this is included: Consistent data standards—such as how phone numbers should be formatted, whether state should be entered as "California" or "CA," what defines a “qualified lead,” or how quickly records should be updated after customer contact—are foundational to reporting accuracy, integration reliability, and user productivity. Without a clear owner responsible for defining and maintaining these standards, they erode over time as different teams interpret standards differently, new users are onboarded without training on standards, and one-off exceptions become de facto new standards. This creates an environment where reports can't be trusted, integrations break due to unexpected data formats, and users waste time cleaning data manually. Assigning explicit ownership ensures standards are defined, documented, communicated, and consistently enforced.

 

Details: Identify a data governance owner or committee responsible for defining data standards, publishing them in an accessible location (such as a Salesforce Knowledge base or team wiki), training new users on standards, monitoring compliance through data quality reports, and updating standards when business needs change. This owner should have authority to make decisions about data format requirements, required vs. optional fields, picklist value standards, and data retention policies. They should also have a regular cadence (monthly or quarterly) for reviewing data quality metrics and addressing emerging issues. For large orgs, consider creating a Data Governance Committee with representatives from key business functions (sales, marketing, support, finance) to ensure standards reflect cross-functional needs.

 

Dos:

• Do publish data standards in an easily accessible, searchable location

• Do include data standards in new user onboarding and ongoing training

• Do create data quality dashboards that make compliance with standards visible

• Do review data standards annually to ensure they still meet business needs

• Do enforce standards through validation rules and automation, not just documentation

• Do recognize and celebrate teams that maintain high data quality

 

Don'ts:

• Don't assume users know the data standards—make them explicit and accessible

• Don't create standards without consulting the teams who will need to follow them

• Don't make standards so rigid they can't accommodate legitimate exceptions

• Don't fail to provide tools (like input masks and default values) that make following standards easy

• Don't let data standards documentation become outdated as business processes change

• Don't assign data standards ownership to someone without the authority to enforce them

Why this is included: Without a defined approval process for new fields and automation, orgs quickly become cluttered with one-off customizations that create long-term maintenance burdens, performance issues, and user confusion. Well-intentioned users create fields and automations that solve immediate problems but don't consider naming conventions, dependencies on other systems, or long-term maintainability. Over time, the org becomes difficult to understand and modify, with duplicative fields, conflicting automations, and technical debt that's expensive to clean up. An approval process with a clear owner ensures that new customizations are evaluated for necessity, alignment with existing data models, naming consistency, and long-term supportability before they're implemented, preventing problems rather than having to fix them later.

 

Details: Establish a clear approval process for new custom fields, objects, flows, and Apex code. Define who has approval authority (typically a Salesforce admin, architect, or governance committee), what information requesters need to provide (business justification, proposed field name and type, whether existing fields could be reused), expected turnaround time, and what criteria will be used to evaluate requests (alignment with data model, alternatives evaluation, naming convention compliance, performance impact). Create a request intake form (using Salesforce Cases, a custom object, or a third-party tool) that captures all required information upfront to avoid back-and-forth. Communicate this process org-wide and make it easy to follow—if the process is too cumbersome, users will find ways to work around it.

 

Dos:

• Do create a simple, documented intake process for customization requests

• Do evaluate whether existing fields or automation can meet the need before creating new ones

• Do enforce naming conventions and document the business purpose in field descriptions

• Do consider long-term maintenance impact, not just immediate functionality

• Do involve the requestor in understanding trade-offs and alternatives

• Do set realistic expectations for turnaround time and communicate status proactively

 

Don'ts:

• Don't create an approval process so bureaucratic it takes weeks to get simple changes approved

• Don't approve requests without understanding the full business context and alternatives

• Don't allow users to create fields and automation without approval just because they have the permissions

• Don't approve requests that duplicate existing functionality just to make one team's workflow slightly easier

• Don't skip reviewing requests for naming convention compliance and completeness

• Don't approve automations without understanding how they'll interact with existing automation

Why this is included: Org hygiene isn't a one-time project—it's an ongoing practice that requires regular attention to prevent regression. Without a defined rhythm of recurring reviews and cleanup activities, the org will inevitably drift back toward the same problems you just spent time fixing: unused fields accumulating, data quality degrading, automations becoming outdated, and reports losing accuracy. A lightweight, sustainable rhythm ensures continuous improvement without overwhelming the admin team, making org health a routine part of operations rather than a crisis-driven initiative that only happens when things break. This item establishes a practical, achievable cadence of hygiene activities that can be maintained throughout the year, ensuring the investment you're making in cleanup now pays ongoing dividends.

 

Details: Design a three-tiered rhythm of org hygiene activities: monthly tasks focused on quick wins and immediate issues (such as reviewing new user access, monitoring data quality dashboards, and checking for automation errors), quarterly tasks focused on deeper reviews (such as auditing reports and dashboards, reviewing approval processes, and assessing field usage), and annual tasks focused on strategic architecture and governance (such as reviewing overall data model, conducting comprehensive security reviews, and evaluating major technical debt items). Document this rhythm in a shared calendar, assign owners for each activity, and track completion in a simple project management tool. Start with a manageable set of activities you can consistently maintain, then add more as the rhythm becomes habitual.

 

Dos:

• Do start with a manageable set of activities you're confident can be completed consistently

• Do assign specific owners and due dates for each recurring task

• Do create simple checklists or runbooks for recurring activities so they're easy to execute

• Do track completion of hygiene tasks and review the process quarterly to identify bottlenecks

• Do celebrate completion of hygiene milestones to maintain momentum and visibility

• Do build hygiene time into team capacity planning—it's part of the job, not extra work

 

Don'ts:

• Don't create an overly ambitious rhythm that can't be sustained with current resources

• Don't skip hygiene activities because "more urgent" work came up—schedule them like any other committed work

• Don't make the rhythm so rigid it can't accommodate shifting business priorities

• Don't assign hygiene tasks without also assigning time and priority to complete them

• Don't assume hygiene activities will happen "when there's time"—they need to be scheduled and protected

• Don't forget to review and adjust the rhythm itself—it should evolve as your org and team mature

Why this is included: Data degrades continuously through normal usage—users enter duplicates, fields become outdated, stale records accumulate, and format standards slip as new users join without proper training. Monthly data cleanup catches these issues while they're still manageable, before they compound into major data quality problems that require large-scale remediation projects. A monthly rhythm is frequent enough to prevent significant degradation but not so frequent that it becomes burdensome. Regular, predictable cleanup also trains users that data quality is an ongoing priority, not something the admin team only cares about once a year during "cleanup projects." This establishes data quality as a continuous practice rather than a reactive crisis response.

 

Details: Establish a monthly data cleanup routine that includes running duplicate reports on Accounts, Contacts, and Leads; reviewing records flagged by data quality rules; updating stale records (such as Leads with no activity in the past 90 days); and spot-checking recent imports and integration data for format consistency. Create saved reports or dashboards that surface these issues automatically so you're not starting from scratch each month. Assign a specific owner and scheduled date for monthly cleanup, and track metrics (such as number of duplicates merged, number of stale records updated) to show progress over time. Communicate cleanup results to the broader team to maintain visibility into data quality efforts and encourage good data entry habits.

 

Dos:

• Do schedule monthly cleanup on the same day each month (e.g., first Friday) so it becomes routine

• Do create saved reports that automatically surface data quality issues so you don't have to rebuild the same reports each month

• Do track data quality metrics month-over-month to show improvement trends

• Do communicate cleanup results to the team to maintain awareness of data quality

• Do automate as much of the cleanup as possible (such as automated duplicate merging with clear rules)

• Do involve power users in monthly cleanup to distribute the workload and build data quality awareness

 

Don'ts:

• Don't let monthly cleanup slip repeatedly—once you break the rhythm it's hard to restart

• Don't spend more than 2-3 hours on monthly cleanup—it should be sustainable, not overwhelming

• Don't try to fix everything in monthly cleanup—focus on high-impact, quick wins

• Don't run bulk data changes without testing in a sandbox first, even for routine cleanup

• Don't clean data without first understanding the root cause—you'll be cleaning the same issues repeatedly

• Don't perform cleanup alone—involve business stakeholders so they understand the data quality challenges their teams create

Why this is included: Automations and reports have a longer shelf life than data but still require regular review to ensure they remain aligned with evolving business processes, organizational structure, and data models. A quarterly rhythm allows you to catch automations that are no longer relevant, reports that are no longer used, dependencies on deprecated fields, and conflicts between different automations—issues that aren't immediately obvious in day-to-day operations but compound over time to create complexity and risk. Quarterly reviews also provide a natural checkpoint to evaluate new requests in context, identifying patterns (such as multiple teams requesting similar reports, suggesting a need for a shared dashboard) and ensuring that changes made during the quarter didn't have unintended side effects.

 

Details: Each quarter, review active Flows, Process Builder processes, and Apex triggers to confirm they're still needed and functioning as intended; audit key reports and dashboards for accuracy and usage; check for automation conflicts (multiple tools updating the same fields); review approval processes to ensure approvers and criteria are still correct; and identify any automation or reports relying on fields scheduled for deprecation. Create a structured checklist for quarterly audits so they're repeatable and don't require starting from scratch each quarter. Assign ownership and schedule a specific time block (such as the first week after quarter close) when the business is typically slower and this work can be prioritized.

 

Dos:

• Do schedule quarterly audits at a consistent, predictable time each quarter

• Do create a standardized checklist or runbook for quarterly audits so they're repeatable

• Do involve business process owners in reviewing automation and reports for continued relevance

• Do track findings from each quarterly audit to identify recurring issues or trends

• Do prioritize fixes based on business impact, not just technical complexity

• Do communicate audit findings and planned changes to affected users before making updates

 

Don'ts:

• Don't skip quarterly audits because the org "seems to be working fine"—problems often aren't visible until they cause incidents

• Don't try to audit everything—focus on high-impact, frequently-used automation and reports

• Don't make changes during quarterly audits without testing in a sandbox first

• Don't audit in isolation—involve users and process owners who understand whether things are working correctly

• Don't defer fixing issues discovered in audits—address high-risk items immediately

• Don't forget to document what you reviewed and what you found—this creates a valuable historical record

Why this is included: While monthly and quarterly hygiene activities focus on tactical maintenance, an annual architecture review provides strategic perspective on your org's overall health, scalability, and alignment with long-term business goals. This is the time to step back from day-to-day firefighting and ask big-picture questions: Is our data model still supporting our business, or has it become a constraint? Are we approaching governor limits or storage limits that will require architectural changes? Are our integrations still the right approach, or should we consider a different integration strategy? • Do our customizations align with Salesforce best practices and new platform capabilities introduced during the year? The annual review identifies structural issues that require significant investment to address, enabling informed prioritization and resource allocation for the coming year.

 

Details: Conduct a comprehensive annual review that includes evaluating your data model against current and anticipated business needs; reviewing integrations for continued fit-for-purpose and identifying consolidation opportunities; assessing custom code for technical debt and identifying opportunities to replace it with clicks-not-code solutions introduced in recent releases; checking resource usage (storage, API calls, CPU time) to identify scalability concerns; reviewing security and compliance posture against current regulatory requirements; and evaluating whether your current Salesforce edition and feature set still meets your needs or if an upgrade and downgrade is warranted. Involve cross-functional stakeholders (business leaders, IT, security, compliance) in this review, and produce a documented report with findings and recommendations that can inform roadmap planning and budget requests for the following year.

 

Dos:

• Do schedule the annual architecture review well in advance and protect the time

• Do involve cross-functional stakeholders, not just Salesforce admins and developers

• Do review Salesforce's last three seasonal releases to identify new features that could replace custom solutions

• Do assess whether your org is approaching technical limits (storage, API calls, number of fields) that will require architectural changes

• Do produce a documented report with findings, recommendations, and estimated effort for remediation

• Do use the annual review to inform next year's roadmap and budget requests

 

Don'ts:

• Don't try to complete an annual architecture review in a single day—block out adequate time

• Don't conduct the review in isolation—include business stakeholders who understand strategic direction

• Don't just identify problems—also recommend solutions and prioritize them

• Don't skip the annual review because you're "too busy"—this is how technical debt compounds into crisis

• Don't forget to celebrate improvements made over the past year—architecture reviews shouldn't only focus on problems

• Don't let the annual review findings sit unused—translate them into actionable plans with assigned ownership