Data cleaning for CRM imports

Salesforce import errors

Fix "DUPLICATES_DETECTED" on a Salesforce import ("Use one of these records?")

This error means a Salesforce duplicate rule fired while importing a row. Salesforce runs your rows through its matching rules and finds a likely match, either against another row in the same file or against a record that already exists in the org, then shows "Use one of these records?" and blocks the row. The durable fix is to dedupe your file first, so far fewer rows trip the rule, and merge the real duplicates into one clean record instead of importing two.

Dedupe your file in Sift, free →

What the error looks like

Salesforce documents this behaviour in its help articles id=000390009 and id=000391118. The duplicate and matching rules fire on import, so a file that loads fine in one org can be blocked in another with stricter rules.

Why it happens

• Duplicates inside your file. The same contact or account appears on two or more rows, so Salesforce matches them against each other during the load.
• Matches against records already in the org. A row in your file looks like a person or company Salesforce already has, and the matching rules flag it before it is created.
• Near-duplicates, not exact repeats. "Jon" and "Jonathan", "ACME" and "Acme Ltd", or a name with an extra initial can all match under fuzzy matching rules even though the text is not identical.
• Same email, different case. Sam@acme.com and sam@acme.com are the same address to a matching rule, so both trip it.
• Whitespace and formatting noise. Trailing spaces and inconsistent casing hide duplicates from your eye while the rule still catches them.

The manual fix

1. Find the duplicates inside your file: sort or filter on email, phone, and name plus company, and scan for the near-duplicates a simple sort misses.
2. For each cluster, decide whether to merge the rows into one or skip the extras, and pick which value wins when two rows disagree.
3. For rows the rule matches against records already in the org, decide at the "Use one of these records?" prompt whether to update the existing record or create a new one.
4. If you would rather import first and clean later, an admin can change the duplicate rule action from Block to Allow with an alert, but understand the tradeoff: it lets more possible duplicates into the org, which is the exact mess you were trying to avoid.

The Sift fix

1. Drop your CSV or Excel file into Sift. It runs in your browser; the file is never uploaded.
2. Run the dedupe pass. Sift finds duplicates with an exact and fuzzy match on an email, phone, and name plus company fingerprint, so Jon and Jonathan or ACME and Acme Ltd land in the same cluster.
3. Merge each cluster into one golden record with survivorship, keeping the best value per field, instead of importing two rows that would trip the rule.
4. Review each cluster with a diff before you accept it, so nothing is merged behind your back.
5. Export a clean, deduped file. Far fewer rows now match each other, so far fewer rows trip the duplicate rule when you import.

What Sift can't fix

Honesty matters here, and this one is important. DUPLICATES_DETECTED also fires when a row in your file matches a record that already exists in Salesforce. Sift cleans your file, but it cannot see inside your org, it has no live connection to Salesforce, so it cannot predict every match against records you already have. It removes the duplicates within your file and reduces the surface that trips the rule, but the org-side matches still need your merge decision at import time or a change to the duplicate-rule setting. Sift also does not enrich, guess, or verify data: it cleans what is in the file, deterministically.

Related guides