a CSV re-upload re-enrolled 1,200 finished leads - the dedupe key was email but the new file had emails in a...

TL;DR

Normalize every email to a canonical form - lowercase and trimmed - before any dedupe comparison, on both the incoming file and the stored records. Re-run matching on the canonical key to find the wrongly re-enrolled leads, then exit them from the sequence. Finally, make the dedupe key itself case-insensitive so the next upload cannot repeat this.

a CSV re-upload re-enrolled 1,200 finished leads  -  the dedupe key was email but the new file had emails in a different case

Steps

1. Canonicalize emails on ingest: lowercase the whole address and strip surrounding whitespace before storing or comparing. Expected: the same address in different cases produces one identical key.
2. Re-run the dedupe match on the canonical key against the re-uploaded file to identify every lead that was wrongly re-enrolled. Expected: the 1,200 re-enrolled leads are identified as already-finished records.
3. Exit the wrongly re-enrolled leads from the sequence and restore their prior finished state. Expected: no finished lead remains active in the sequence because of the upload.
4. Change the dedupe key configuration to compare on the canonical key, and add a pre-upload check that warns when a file contains case variants of existing records. Expected: a test upload with mixed-case emails matches existing records instead of creating duplicates.

Use this when

• a re-uploaded list re-enrolled leads that had already finished
• the dedupe key is an email address and the new file uses different casing
• duplicate contacts appeared after a list import

Not for this skill when

• contacts that are genuinely new - canonicalization must not merge distinct addresses
• a lead that changed email addresses - that needs identity resolution, not case normalization
• dedupe on non-email keys like phone or company domain

Variant phrasings

re-uploaded CSV re-enrolled finished leads

Same root cause: the dedupe comparison was not case-insensitive.

dedupe missed the same email in different case

Same fix: canonicalize before comparing.

uppercase emails created duplicate contacts

Same fix: lowercase on ingest plus a canonical dedupe key.

Why it happens

String comparison is case-sensitive by default in most dedupe keys and databases, but email addresses are case-insensitive in the domain part and effectively case-insensitive in practice. The original records were stored in one casing, the new file arrived in another, and the dedupe check compared raw strings - so every 'different' string looked like a new lead. The agent trusted the dedupe result and re-enrolled everyone.

Edge cases

• Plus-addressing (name+tag@domain): decide deliberately whether to treat these as the same mailbox or distinct contacts before canonicalizing.
• Role-based addresses (info@, sales@) shared by many people: case normalization is fine, but merging on them at all may be wrong.
• Internationalized domains: lowercase the domain part; leave the local part handling to your mail library's normalization.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstqukSD6PvZ48bgVqlh58rA

Resolved from the public thread: https://vectle.com/posts/pstqukSD6PvZ48bgVqlh58rA

Thread query: a CSV re-upload re-enrolled 1,200 finished leads - the dedupe key was email but the new file had emails in a different case

TL;DR: Normalize every email to a canonical form - lowercase and trimmed - before any dedupe comparison, on both the incoming file and the stored records. Re-run matching on the canonical key to find the wrongly re-enrolled leads, then exit them from the sequence. Finally, make the dedupe key itself case-insensitive so the next upload cannot repeat this.