Original worked guide / 2026-10-05
Duplicate customer IDs in CSV: keep conflicting records
An exact duplicate repeats every field. A conflicting customer ID repeats the key while other fields differ. Removing one conflicting row can lose the more accurate contact, so decide a resolution rule before importing. This worked example retains all records with a repeated key for human review.
By Hasnain Qureshi / Karachi, working remotely with UK and US teams.
Five records, three customer IDs
Download the conflicting-ID sample and open it in the CSV Cleaner & Import Checker. Keep Remove exact duplicate rows off for the first check so that you can inspect all repeated-key records.
| Customer ID | Records | Interpretation |
|---|---|---|
| 001 | Alice / alice@example.com and Alice Smith / alice.smith@example.com | Conflicting fields; both require a decision |
| 002 | Bob / bob@example.com | Uncontested in this file |
| 003 | Two identical Cara records | Repeated key with identical fields |
Check the selected key
- Enable source headers and choose Customer ID in Check repeated keys in output.
- Run the check with quarantine off. Five records remain; four require review and block the clean download. The tool has not decided which contact is current.
- Turn on Move missing required fields and repeated-key records into a separate unresolved file and recheck. Bob is the one uncontested row. All four repeated-key rows remain in the unresolved download.
- Compare the clean result with the expected uncontested output. Inspect the unresolved file before making any business decision.
- If you explicitly enable exact duplicate removal, one Cara row is removed and retained separately. The surviving Cara row is no longer a repeated key within the cleaned file; the conflicting Alice records still require review.
Agree a resolution policy
An ID duplicated in an export might mean an old and new address, a legitimate one-to-many relationship or an upstream bug. Consult the source owner and destination semantics. A “keep latest” rule needs a reliable timestamp and a rule for ties or missing timestamps. A “keep most complete” rule can combine unrelated people if the key itself is wrong.
Case-insensitive matching is optional and should be chosen only when the selected key uses that policy. Leading zeros stay intact. Trimming surrounding whitespace happens only when chosen. Names and company names are usually poor substitutes for a stable identifier.
A clean file is not a destination comparison
This browser tool sees only the uploaded file. It cannot tell whether Bob already exists in your CRM or whether an external ID matches the target record. Repeated product identifiers may represent legitimate variants or line items. Never apply a customer uniqueness rule to them without checking the destination.
For recurring migrations or synchronisation, custom data import and integration development can add destination comparisons, review decisions and an audit trail. First prepare an explicit destination mapping and preserve both the original source and each unresolved record.
Discuss duplicate handling in your application
Share the current workflow, constraints and desired outcome. We can review scope and agree what needs implementation.