A clean CSV can still create messy Salesforce data. Before importing a new contact list, check both how the import finds existing records and how your org reacts to potential duplicates. These are related controls with different jobs.
Two matching decisions to review
The Data Import Wizard’s matching option determines whether incoming data is associated with an existing record. For contacts, available choices include Salesforce ID, name, email, and external ID. A matching rule defines which Salesforce records look like duplicates; a duplicate rule decides what happens when a potential duplicate is detected.
Choosing email as your import matching option does not replace a review of active duplicate rules. Likewise, a duplicate warning is not a promise that an import will update the record you intended.
Example: a conference contact list
Suppose your team has 250 fictional conference contacts to load. Some already exist, some use a changed email address, and two people share a general inbox. Your goal is to create new contacts and enrich existing ones without combining different people.
Before touching production, export the records and fields you might change, keep the original CSV, and agree with the data owner on which values may be overwritten. Use non-sensitive test data in a sandbox.
Inspect the configuration
- In Setup, find Matching Rules. For Contact, review active criteria, exact or fuzzy comparison, and the fields involved. Note what would distinguish two people at the same company.
- Find Duplicate Rules. Review active Contact rules, their conditions, and the actions configured for create and edit. Check which matching rules each uses.
- Choose the import operation deliberately: add, update, or add and update. Where the file contains known Salesforce records, reliable record IDs can make the intended target explicit.
- Review every field mapping. Remove columns you do not intend to change, and verify account association separately from contact matching.
Run a five-row test
- New person: a contact with no intended match.
- Known contact: the same person with a trusted identifier.
- Changed email: an existing person whose email differs from the file.
- Shared inbox: a different person with an email already used elsewhere.
- Near match: a name or address variation that exercises your matching criteria.
Write down the expected result for each row before importing. Use the same operation, mappings, and representative importer access planned for the real load. Record which rows were created, updated, or rejected, then inspect the actual Salesforce records and their account links.
Investigate rejected rows before retrying
Salesforce documents that duplicate detection can stop imported rows, including an Allow-with-Alert configuration in the Data Import Wizard. Do not assume a user interface warning can be bypassed in a bulk import. If you see DUPLICATES_DETECTED, inspect the matching records and applicable rule instead of repeatedly resubmitting the entire file.
Reconcile successes and failures first. Correct only the failed rows and retest them; replaying successful inserts can create another cleanup problem. Avoid disabling duplicate protection simply to make the job finish.
Limits and a production checkpoint
This is a testing method, not a universal duplicate-rule recipe. Your object, import tool, record access, automation, and rules determine the outcome. Duplicate management does not automatically merge your existing records. Review false positives with the data owner before tightening a rule.
Proceed with the full load only after the sample behaves as intended, the recovery plan is clear, and someone is responsible for reviewing results. Keep the mappings, sample outcomes, and error log with the import record.
Official Salesforce references
- Matching rules and duplicate rules explained
- Business account and contact import matching
- Import with the Data Import Wizard
- Duplicate detection during data imports
Published October 9, 2026. Example data is fictional; official references checked on this date.