Enriching CRM records is simple to describe and easy to get wrong in production. Pulling company and contact detail from Clearbit and Lusha into Pipedrive through n8n sounds like three API calls and a mapping step, but a workflow that holds up under real lead volume needs retry logic, domain filtering, suppression list checks and a field mapping strategy that survives a schema change in any one of the three tools. This piece works through how to build that workflow properly, where Clearbit and Lusha genuinely differ, and the failure modes that catch most RevOps teams the first time they wire this up.
Why Enrichment Breaks Down Without Automation
Manual enrichment usually starts well and decays. A rep opens LinkedIn, copies a job title into Pipedrive, and moves on. Multiply that across every new lead in the pipeline and the format drifts: “VP Sales”, “VP of Sales” and “Vice President, Sales” all describe the same role but read as three different values to any rule that matches on exact text. Because Pipedrive automations and most scoring logic key off exact field values rather than fuzzy matching, a rule built around “seniority contains VP” quietly stops firing for a chunk of the records it should catch, and nobody notices until pipeline reporting looks wrong weeks later.
The second failure mode is coverage rather than format. Reps under quota pressure enrich the records they are about to call and skip the rest, so the database ends up with a small set of well maintained records and a long tail of blank fields. That tail is exactly where lead routing and scoring rules fail silently, because a rule that checks company size or industry has nothing to route on when the field is empty.
The third is provenance. When enrichment happens by hand there is no record of when a field was set, from what source, or whether it has been checked since. That matters the first time a deal is disputed or a scoring model needs debugging, because there is no way to tell whether a “Company Size: 500” value is six months old, six weeks old, or where it came from in the first place.
Building the Pipedrive and n8n Automation Layer
The workflow starts with a trigger, not an API call. n8n listens for Pipedrive webhook events such as a new person being created or a deal moving stage, using the subscription mechanism described in Pipedrive’s developer documentation. That event fires the rest of the chain automatically, so enrichment happens the moment a record exists rather than whenever a rep next opens it.
Inside n8n, the chain is usually a webhook trigger node, an HTTP Request node calling Clearbit, an IF node checking whether the match is confident enough to continue, a second HTTP Request node calling Lusha, and a Pipedrive node writing the results back. Because each of those steps is a separate node on a visual canvas, n8n’s execution history lets you inspect exactly what happened at each stage for a specific contact, which matters far more than it sounds like it should the first time a field fails to populate and you need to know whether Clearbit returned nothing or the mapping step dropped it.
Self-hosting n8n gives full control over where credentials sit and how rate limiting logic is written, but it puts the operational burden of running workers and queue mode on your own infrastructure once volume climbs. n8n Cloud removes that hosting burden but ties execution timing and limits to n8n’s own plans. Full setup detail for either path is in n8n’s documentation. Most teams start self-hosted for a low volume pilot and move to queue mode, self-hosted or cloud, once enrichment volume makes a single execution worker a bottleneck.
A detail teams miss early is idempotency. Without a check, every minor update to a person record (a note added, a stage change) can re-trigger the whole enrichment chain and burn paid API calls on a record that was enriched an hour ago. Writing a custom field such as last_enriched_at and checking it before firing Clearbit or Lusha turns enrichment into a controlled, once-per-record cost rather than an open-ended one that scales with every unrelated CRM edit.
Where Clearbit and Lusha Each Earn Their Place
Clearbit works from the email domain. Give it a domain and it returns company level data: employee count, industry, location and an inferred technology stack built from public signals such as job postings and website scans. Because the lookup is domain based rather than person based, match rates are high and the call is cheap, which is why it makes sense as the first enrichment step rather than the last.
That technographic detail comes with a caveat worth planning around: it is inferred, not confirmed. A company that switched CRM platforms last month may still show the old tool in Clearbit’s data until public signals catch up, so technographic fields are useful for segmentation and messaging angles, not for anything that needs to be current to the week.
Lusha does the opposite job well: verified direct dials and personal emails at the contact level. Match rates here vary far more by seniority and region than Clearbit’s do, and UK small and mid-sized companies in particular tend to have thinner public contact data available than larger enterprises with more of an online footprint, so a UK focused pipeline should expect a lower Lusha hit rate than a US enterprise one.
The practical sequencing rule follows from those two profiles: run Clearbit first because it is cheap and reliable, then only spend Lusha credits on contacts that clear a qualification threshold from the Clearbit result. Firing Lusha at every new lead regardless of fit burns a per-credit budget on records that will never make it to a call.
The Enrichment Workflow Step by Step
Trigger: New Contact or Deal Stage Change
Person creation is the most reliable trigger point, since it applies the same enrichment to every new contact regardless of source, whether that is a form fill, an imported list or manual SDR entry. Triggering later, on deal stage change, means reps work the first few touches with incomplete data. Triggering earlier, on a raw form fill before any qualification, means paying for enrichment on records that will be discarded within a day.
Company Lookup via Clearbit
The workflow extracts the domain from the contact’s email address and calls Clearbit’s company endpoint. The response is written to custom fields alongside a match confidence value, which becomes the gate for whether the workflow proceeds to a contact level lookup at all.
Contact Lookup via Lusha
An IF node checks the Clearbit confidence field and, separately, whether the company matches basic ideal customer profile criteria such as size or industry. Only records that clear both go on to the Lusha call. Everything else stops here with firmographic data filled in but no direct dial spend against it.
Field Mapping Back into Pipedrive
This is where a surprising number of enrichment workflows quietly break. Clearbit’s and Lusha’s JSON responses use their own key names, which rarely match Pipedrive’s custom field API keys, so the mapping step in n8n needs to reference explicit field IDs rather than relying on name matching. When Clearbit changes its response schema, and it does without much notice, a workflow built on exact field ID mapping fails loudly with a clear error in n8n’s execution log. One built on loose name matching just stops filling a field, and that goes unnoticed for weeks.
Handling Failures: Retries, Rate Limits and Bad Matches
The most common source of bad data is not a broken workflow but a wrong input: firing a company lookup against a personal email domain such as Gmail, Outlook or Yahoo returns nothing useful from Clearbit, and in some cases can attach a plausible looking but wrong company to a shared or generic corporate domain. Filtering out free and webmail domains before the lookup even runs, using a maintained list checked in an IF node, removes this class of error before it reaches the CRM.
Both providers cap requests per minute or per day, and a workflow that treats a 429 rate limit response the same as a genuine no-match result will mark perfectly good leads as “enrichment failed” simply because too many calls went out in a short window. The fix is to branch on the HTTP status code specifically and hold rate limited records for retry rather than failing them outright.
The diagram below shows how this plays out end to end: a Clearbit lookup that returns no match goes into a retry queue capped at three attempts spaced apart, since a no-match is often temporary rather than a genuine absence of data. If all three attempts fail, the record is flagged for manual review instead of looping indefinitely or sitting blank with no indication anything went wrong.
Governance: GDPR, Suppression Lists and Data Minimisation
B2B contact enrichment is generally workable under a legitimate interests basis, since it enriches a business contact’s professional details rather than special category personal data, but that basis needs to be documented, not assumed. The ICO’s guidance for organisations is the right starting point for working out what a legitimate interests assessment needs to cover for this kind of processing.
Before any lookup fires, the workflow should check the contact against a suppression list. Retrieving someone’s personal mobile number through Lusha after they have already objected to being contacted compounds the problem later, even though the enrichment call itself is not the outbound contact, because the number then exists in the CRM ready for a rep to dial.
Data minimisation means only pulling fields the workflow actually uses downstream. Every enriched field should be written alongside its source and timestamp, both to answer the provenance problem raised earlier and to give a straightforward audit trail if a contact later asks what data is held on them and where it came from.
Keeping the Workflow Accurate as Volume Grows
A single monolithic workflow handling every lead source works fine at low volume and becomes a liability at scale, because a Clearbit outage or a schema change on one segment then blocks enrichment for every other segment too. Splitting workflows by lead source, geography or product line means a fault in one branch does not stall the rest of the pipeline.
Enrichment success rate is worth tracking as its own metric, not inferred from complaints. A sudden drop, tracked through n8n’s execution history and alerted on, is usually the first sign of a provider schema change or a credential expiring, both of which are far cheaper to catch within a day than to discover a month later when a whole cohort of leads turns out to be missing fields. Details on execution history and monitoring are covered in n8n’s documentation.
Treat changes to the workflow the way you would treat a code deployment: test against a small subset of records before applying a mapping change to the live pipeline. Clearbit and Lusha have both changed response formats without much advance notice in the past, and a workflow that maps by explicit field ID will fail obviously on a test batch of fifty records rather than silently on the next ten thousand.
Related Reading
For more on this, see our automation and n8n coverage, including Automate Pipedrive Contact Enrichment with Clearbit and n8n, RevOps Coaching, CRM Integration and SEO for SaaS Growth, and Boost SaaS Growth with n8n Multi-Touch Engagement Tracking.
Frequently Asked Questions
What should trigger the enrichment workflow in Pipedrive?
The most reliable trigger is person creation, either from a form submission, an imported list or manual entry by an SDR, rather than waiting for a deal stage change. Triggering on person creation means every new contact gets the same enrichment treatment before anyone works it, so reps are never the ones deciding which records get enriched.
Why run the Clearbit lookup before Lusha instead of firing both at once?
Clearbit’s company level lookup is a cheap, high match rate call keyed off the email domain, while Lusha’s contact level lookup is priced per credit and has a lower match rate for smaller or UK based companies. Gating the Lusha call behind a successful Clearbit match and a basic qualification check stops the workflow spending contact level credits on leads that turn out not to fit the ideal customer profile.
What happens when Clearbit or Lusha returns no match for a lead?
The record goes into a retry queue capped at three attempts spaced apart, since a no match result is often a temporary rate limit or a timing issue rather than a genuine absence of data. If all three attempts fail the record is flagged for manual review instead of being left blank or retried indefinitely, which keeps the queue from growing unbounded.
Is calling Clearbit or Lusha from an automated workflow compliant with GDPR?
It can be, provided the workflow checks a suppression list before firing any lookup and the enrichment is covered by a documented legitimate interests assessment, since B2B contact enrichment is enrichment of a business contact rather than a special category of personal data. The ICO’s guidance for organisations is the right starting point for working out lawful basis and documentation.
How do you stop the workflow spending API credits on leads that will never be worked?
By filtering out generic or free email domains such as Gmail or Outlook before the Clearbit call runs, since a company level lookup against a personal email address returns nothing useful, and by gating the Lusha contact lookup behind a minimum qualification threshold from the Clearbit result rather than enriching every record to the same depth.
Leave a Reply