How the Salesforce import avoids creating duplicates

IMPORTING THE SAME EXPORT TWICE

Every imported record is stamped with its Salesforce id. Importing the same export again finds that stamp and UPDATES the record rather than making a second one. This is what makes it safe to retry an import that half-failed, or to re-export from Salesforce after fixing a few rows and upload the whole file again.

MATCHING AGAINST RECORDS YOU ALREADY HAVE

Before writing anything, the import compares each incoming row against what is already in your org:

• Companies match on web domain first, then on name with the legal suffix and punctuation removed -- so "Acme Corp.", "ACME Corporation" and "Acme, Inc." are recognized as one company. Free email hosts (gmail.com, outlook.com and the like) are never treated as a company domain, because two customers with Gmail addresses are not the same company.
• People match on email. A Lead and the Contact it was converted into share one email, so they arrive as one person rather than two -- which is what you want, since converting a lead in Salesforce leaves both rows behind.
• Products match on SKU within a store, ignoring case and separator differences.

A NAME-ONLY MATCH IS NOT TREATED AS A MATCH

If two records share nothing but a normalized name, the import SKIPS the row and tells you, rather than merging them. Merging two genuinely different companies is much harder to undo than having two rows, so the default is to leave the decision to you. Review the pair, and if they really are the same, re-run with weak matching enabled.

WHEN THE DUPLICATE CHECK IS PARTIAL

Comparing names and domains requires holding your existing records in memory, which is bounded. If your org has more records than the scan limit in a collection, the preview says "Duplicate check was partial" and names the collection. Records may then be created that duplicate ones already there.