Define what counts as a duplicate before removing anything. Exact duplicate rows and records matching on selected fields are different cases. Review the groups, choose the record to keep and confirm the proposed removals before exporting.
Separate repeated rows from repeated identities
An exact duplicate row repeats the same values across the fields being considered. A duplicate contact can be less obvious: two rows may share an email while one has a phone number and the other does not. Removing only exact repeated rows will not resolve every repeated identity.
The reverse mistake is also possible. Two people can share a name, and a company can have several legitimate contacts. Similar-looking text does not by itself establish that records are duplicates.
Choose matching columns deliberately
Choose a key that represents identity in the file's business context. An email may suit some contact lists; a stable company identifier may suit organization records. When matching on multiple fields, understand that the selected fields must satisfy the configured rule together.
Treat missing keys cautiously. Blank email addresses do not establish that two people are the same. Inspect those records rather than assuming a group of missing values is a duplicate group.
- Identify the business record represented by each row.
- Select fields that are suitable for matching.
- Review missing identifiers separately.
Apply only the normalization you intend
Ignoring capitalization or trimming surrounding spaces can make selected keys comparable. For example, 'ALEX@EXAMPLE.COM' and 'alex@example.com' can match when capitalization is ignored. Those rules do not make 'Alex Smith' and 'Alexander Smith' the same person.
Keep a note of the rules used, and inspect example groups after changing them. In RowDesk, advanced duplicate matching uses selected columns and conservative normalization, not fuzzy or AI identity matching.
Review which record should survive
Compare the available fields within each group. Keep Most Complete recommends the record with the most non-empty values across output columns. This can preserve more populated fields, but it does not establish that they are current or correct.
Choose another record manually when the available business context supports it. Keeping one row is not the same as merging values from all rows; inspect information present only in the records proposed for removal before confirming the decision.
Check removal counts and preserve the original
Distinguish duplicate groups from records involved and rows removed. If three groups contain 3, 2 and 4 records, there are 9 records involved. Keeping one per group means removing 6 rows, not 3 or 9. With 100 original rows and no other removals, the final count is 94.
Preview the removal, inspect the consequences and export a separate CSV. In RowDesk, review and undo apply during the active session. Save the outputs you need before closing it; do not treat session history as permanent storage.
- Review matching rules and survivor choices.
- Check proposed removals against group sizes.
- Verify the final count and retain the original file.