Why this is included: Duplicate records are one of the most common and damaging data quality issues in Salesforce. They cause sales reps to work the same prospect twice, result in duplicate communications to customers, inflate pipeline and reporting metrics, and make it impossible to get a single, accurate view of a customer relationship. Duplicates often enter the org through data imports, web-to-lead forms, manual entry, and integrations that lack deduplication logic. Left unaddressed, duplicates compound over time and become increasingly expensive to clean up.

 

Details: Use Salesforce's native Duplicate Management framework — Matching Rules and Duplicate Rules — to identify and prevent duplicates. For a one-time cleanup, run reports using the standard Duplicate Record Sets object to surface records flagged by your matching rules. For more sophisticated deduplication, consider third-party tools such as DemandTools, Cloudingo, or Validity (formerly RingLead). Before merging, establish a merge hierarchy — for example, the oldest record wins, or the record with the most complete data wins — and document it so the process is repeatable. After the initial cleanup, activate Duplicate Rules with the "Block" or "Allow with Alert" action to prevent new duplicates from being created.

 

Dos:

• Do establish a merge hierarchy before bulk merging to ensure consistent outcomes.

• Do back up your data before running any bulk merge operation.

• Do involve business stakeholders (sales ops, marketing ops) in defining what constitutes a duplicate for each object.

• Do activate Duplicate Rules in production after cleanup to prevent recurrence.

 

Don'ts:

• Don't merge records without reviewing the data on both records — automated merges can result in data loss if the wrong record is designated as the master.

• Don't run bulk merges directly in production without testing in a sandbox first.

• Don't rely solely on exact-match logic — fuzzy matching (e.g., "Acme Corp" vs. "Acme Corporation") is essential for catching real-world duplicates.

• Don't skip custom objects — duplicates in custom objects like Projects, Contracts, or Subscriptions can be just as damaging as duplicates on standard objects.

Why this is included: Inconsistent data formats and picklist values make reporting unreliable, break integrations that expect specific values, and create a poor user experience. When users enter data in different formats — phone numbers as "(555) 123-4567" vs. "5551234567," or states as "CA" vs. "California" — it becomes impossible to group, filter, or aggregate that data accurately. Picklist values that have been added ad hoc over time often contain duplicates, typos, or obsolete options that confuse users and pollute reports.

 

Details: Run field-level reports to identify values that don't conform to expected formats — for example, phone numbers that don't match a standard pattern, or email addresses that lack an "@" symbol. Use Data Loader to standardize values in bulk. Review all picklist fields across key objects and compare active values against what is actually being used in records. Deactivate or replace obsolete picklist values, and add any missing values that users have been working around with freeform text. Implement validation rules to enforce format standards at the point of entry going forward.

 

Dos:

• Do use validation rules to enforce data format standards (e.g., phone number format, required fields on record save).

• Do review picklist values with business stakeholders to confirm which values are still relevant.

• Do use global picklists for values that are shared across multiple objects to ensure consistency.

• Do document the standard formats for key fields (phone, address, date) and communicate them to users.

 

Don'ts:

• Don't delete picklist values that are still in use on existing records — deactivate them instead to preserve historical data while preventing future use.

• Don't add validation rules without testing them against existing data first — a new rule can block users from saving records that already violate the format.

• Don't overlook formula fields and roll-up summaries that may be affected by picklist value changes.

• Don't rely on users to self-correct data entry — enforce standards through validation rules and input masks wherever possible.

Why this is included: Stale records — such as Leads that haven't been contacted in over a year, Opportunities stuck in "Prospecting" for six months, or Contacts with no associated activity — clutter the org, distort pipeline and funnel metrics, and make it harder for reps to focus on active work. They also consume storage, slow down list views and reports, and can trigger automation (e.g., scheduled flows or email alerts) on records that are no longer relevant. Defining and enforcing staleness thresholds is a key part of maintaining a healthy, actionable CRM.

 

Details: Work with business stakeholders to define staleness thresholds for each object — for example, Leads with no activity in 12 months, Opportunities with no stage change in 90 days, or Contacts with no associated Account. Build reports to surface these records and present them to the relevant team for review. Options for handling stale records include updating them with current information, converting Leads to Contacts, closing Opportunities as "Lost," or archiving records using a custom "Archived" status. For very large volumes, consider a data archiving solution such as Salesforce's Big Objects or a third-party archiving tool to move historical records out of the active dataset.

 

Dos:

• Do involve sales and marketing leadership in defining staleness thresholds — these are business decisions, not just technical ones.

• Do create a recurring report or dashboard to surface stale records on an ongoing basis, not just as a one-time cleanup.

• Do use a custom "Archived" status or record type to flag records that have been reviewed and determined to be inactive, rather than deleting them outright.

• Do consider the impact on reporting before archiving — ensure historical data is still accessible for trend analysis.

 

Don'ts:

• Don't delete stale records without confirming there is no compliance or legal requirement to retain them.

• Don't archive records that are still referenced by active records (e.g., a Contact linked to an open Case).

• Don't apply a one-size-fits-all staleness threshold across all objects — the right threshold varies significantly by object and business context.

• Don't skip communicating the cleanup to the sales team — reps may have context on "stale" records that isn't captured in the system.

Why this is included: A data cleanup effort is only as durable as the processes that feed data into the org. If the root cause of bad data — a poorly configured import template, a middleware integration without deduplication logic, or a web-to-lead form with no validation — is not addressed, the org will return to its previous state within weeks. Data quality is not a one-time project; it requires ongoing governance of every data entry point. This item ensures that the cleanup investment is protected by addressing the sources of bad data, not just the symptoms.

 

Details: Inventory all data entry points: manual entry, CSV imports via Data Loader, web-to-lead and web-to-case forms, middleware integrations (e.g., MuleSoft, Boomi, Zapier), and native Salesforce integrations (e.g., Marketing Cloud, CPQ). For each, review whether deduplication logic is applied before records are created or updated, whether field mappings are validated against current field definitions, and whether error handling is in place to catch and alert on failed records. Review integration logs for recurring errors or high volumes of skipped records, which often indicate silent data quality failures.

 

Dos:

• Do implement a data governance review process for any new import template or integration before it goes live in production.

• Do use Salesforce's Duplicate Rules as a safety net to catch duplicates introduced by integrations.

• Do set up error notifications for integration failures so that data quality issues are surfaced immediately rather than discovered weeks later.

• Do periodically re-validate field mappings in integrations, especially after Salesforce releases or org customization changes.

 

Don'ts:

• Don't assume that a working integration is a correct integration — validate the data it produces against expected outcomes regularly.

• Don't allow bulk imports without a pre-import data quality check (deduplication, format validation, required field check).

• Don't skip testing integration changes in a sandbox before deploying to production.

• Don't overlook middleware logs — errors that are silently swallowed by a middleware layer can result in missing or corrupted records in Salesforce.

Why this is included: Salesforce orgs accumulate custom fields over time as teams request new fields for specific projects, campaigns, or integrations that are later abandoned. These "junk drawer" fields clutter page layouts, confuse users, slow down record load times, and make the data model harder to understand and maintain. Fields that are never populated also consume metadata limits — Salesforce enforces a cap on the number of custom fields per object — and can interfere with integrations that map all fields indiscriminately.

 

Details: Because Salesforce no longer provides robust native field-usage analysis, use third-party tools such as Elements.cloud or Metazoa Snapshot, or export metadata and field population data to Excel for analysis. For each low-usage field, investigate whether it is intentionally optional (e.g., a field that only applies to a subset of records), recently added and not yet populated, or genuinely abandoned. Consult with the field's creator or the relevant business team before removing it. Fields that are confirmed as unused should be removed from page layouts first, then deleted after a waiting period to confirm no downstream impact.

 

Dos:

• Do run audits regularly — it provides visibility into unused fields, among other issues.

• Do remove unused fields from page layouts before deleting them, and monitor for any complaints before proceeding with deletion.

• Do document the purpose of each custom field in the field description — this makes future audits significantly easier.

• Do check whether unused fields are referenced in reports, list views, formulas, flows, or Apex code before deleting them.

 

Don'ts:

• Don't delete a field without first checking all dependencies — Salesforce will warn you about some, but not all (e.g., fields referenced in Apex code or external integrations).

• Don't assume a field is unused just because it has a low population rate — it may be critical for a small subset of records.

• Don't skip the field description when creating new fields — undocumented fields become tomorrow's cleanup problem.

• Don't allow users or teams to create custom fields without a review process — establish a field request and approval workflow to prevent future accumulation.

Why this is included: As Salesforce orgs scale, data storage costs increase significantly — Salesforce charges for storage overages, and large data volumes can degrade query performance, slow down list views, and increase report run times. Objects like Activities (Tasks and Events), Cases, and custom log or transaction objects can grow to tens of millions of records over several years. Without a proactive archiving strategy, orgs face escalating storage costs, degraded performance, and increasingly complex data management challenges. Archiving also supports compliance by ensuring that data is retained for the required period and then disposed of appropriately.

 

Details: Identify high-volume objects by reviewing storage usage under Setup > Storage Usage. For each high-volume object, define a retention policy in collaboration with legal, compliance, and business stakeholders — for example, retain Cases for 7 years, then archive. Archiving options include Salesforce Big Objects (for storing large volumes of historical data within Salesforce), external data lakes (e.g., Amazon S3 integrated through Salesforce Connect for federated access), and third-party archiving tools such as Ownbackup or Spanning. Ensure that archived data remains accessible for reporting and compliance purposes, even if it is no longer in the active Salesforce dataset.

 

Dos:

• Do define retention policies for each major object before implementing archiving — archiving without a policy can create compliance gaps.

• Do test archiving processes in a sandbox before running them in production.

• Do ensure that archived data is still accessible for legal holds, audits, and regulatory inquiries.

• Do monitor storage usage on a monthly basis and set up alerts when usage approaches defined thresholds.

 

Don'ts:

• Don't archive records that are still referenced by active records — this can break relationships and cause errors in the UI and API.

• Don't treat archiving as a substitute for data governance — archiving moves the problem, it doesn't fix the root cause of data accumulation.

• Don't delete records as part of an archiving process without confirming that a backup or archive copy exists.

• Don't overlook the impact of archiving on integrations — external systems that sync with Salesforce may need to be updated to handle archived records.

Why this is included: Sensitive data — including personally identifiable information (PII), payment card data, health information, and government-issued identifiers — is subject to a growing body of privacy and security regulations including GDPR, CCPA, HIPAA, and PCI DSS. Storing sensitive data in Salesforce without appropriate controls (encryption, access restrictions, retention limits) creates significant legal, financial, and reputational risk. This ensures sensitive data is identified, protected, and disposed of in accordance with regulatory requirements, while establishing a repeatable compliance process as regulations evolve.

 

Details: Begin by conducting a data inventory to identify which Salesforce objects and fields store sensitive data. Common examples include Social Security Numbers, date of birth, credit card numbers, health conditions, and passport numbers. Confirm that Salesforce Shield Platform Encryption or Classic Encryption is applied to fields containing sensitive data — note that these two encryption models have different capabilities and limitations. Review data retention policies to identify records that should be deleted or anonymized — for example, former customers who have submitted a GDPR right-to-erasure request. Implement a process for handling data subject requests (access, deletion, portability) within the required regulatory timeframes.

 

Dos:

• Do conduct a formal data inventory to map sensitive data to specific Salesforce fields and objects.

• Do use Salesforce Shield Platform Encryption for fields that require encryption at rest, and understand its limitations (e.g., encrypted fields cannot be used in certain formula fields or reports).

• Do implement a process for handling data subject requests (GDPR Article 17, CCPA deletion requests) within the required timeframes.

• Do review sensitive data handling practices whenever a new regulation comes into effect or your business expands into a new jurisdiction.

 

Don'ts:

• Don't store sensitive data in freeform text fields (e.g., Description, Notes) where it cannot be encrypted or easily identified.

• Don't assume that Salesforce's default security model is sufficient for sensitive data — additional controls (encryption, field-level security, audit logging) are required.

• Don't delete records in response to a data subject request without first confirming there is no legal hold or contractual obligation to retain them.

• Don't overlook sandbox environments — sensitive production data that has been copied to a sandbox for testing must be anonymized or scrubbed before the sandbox is shared with developers or third parties.