Deduplicate before you enrich, not after
Running enrichment on duplicate records wastes credits, pollutes your CRM, and creates conflicting data that's harder to clean than the duplicates were.
The standard advice is to clean your CRM. The order matters more than most people acknowledge.
If you run enrichment before deduplication, you end up with two records for the same contact (one enriched with Clearbit data, one enriched with Apollo data) and now your deduplication logic has to reconcile conflicting field values. Which phone number is correct? Which job title is current? You’ve turned a deduplication problem into a data conflict problem.
The correct order: deduplicate first, enrich second.
For deduplication, the matching logic I use in Clay and n8n:
Primary match: exact email match. If two records share an email, they’re the same person.
Secondary match: domain + first name + last name. Catches records where the email was entered differently (gmail vs work email) or one record is missing an email entirely.
Tertiary match: LinkedIn URL. Often the most reliable unique identifier for a person, especially if you’re pulling from multiple list sources.
When a duplicate is found, the merge logic matters. Keep the oldest record (preserves activity history). Pull forward any enriched fields from the newer record that are empty on the older one. Archive the newer record rather than deleting it. You may need the activity history.
One thing worth noting: deduplication is not a one-time project. It’s a continuous workflow. New records come in from forms, enrichment runs, list imports, and manual entry. The deduplication logic needs to run on net-new records as they arrive, not just quarterly when the CRM is visibly dirty.
A Clay table that checks incoming records against existing CRM data before writing them in catches duplicates at the source. Much cheaper than cleaning up after the fact.