Most “CRM enrichment” builds are really just a single API call bolted onto a Pipedrive webhook: a new contact arrives, Clearbit or Lusha gets queried, a few fields get filled in, and the workflow is called finished. That works for a demo. It falls over within a few weeks of real lead volume, because it ignores three problems that only show up in production: enrichment providers cannot match every contact the same way, write backs collide with fields a rep has already edited by hand, and every lookup carries a cost and a rate limit that has to be managed on purpose rather than discovered by accident. This post covers how to build the Pipedrive, n8n, Clearbit and Lusha pipeline properly: where each provider is strong, how to sequence the calls so you are not paying for lookups that were always going to fail, how to protect manually entered data, and what GDPR requires before any of this goes live.
Why CRM Enrichment Breaks Down at Scale
Manual enrichment does not fail because reps are careless. It fails because looking someone up on LinkedIn, checking Companies House, and guessing at company size does not scale past a small volume of leads a week before it turns into a permanent backlog that nobody owns. Once that backlog exists, the fields sales relies on for scoring and routing start reflecting whatever was true when the contact was created, not what is true now.
That “enrich once at import” pattern is the second failure mode, and it is more damaging than an empty backlog because it looks fine on the surface. A contact enriched on day one keeps whatever job title, company size, or segment tag the workflow assigned then. When that person changes role, or their employer is acquired, nothing updates. Lead scoring and territory routing keep firing against data that was accurate once and is now quietly wrong, and because the field is populated, nobody flags it for review.
Import bursts create a third, more mechanical problem. A one-off CSV import of a few thousand contacts hitting an enrichment API all at once will trip rate limits and produce partial failures in a way a live, one-contact-at-a-time trigger never does, and because nobody is watching a bulk import job the way they watch a production pipeline, those failures go unnoticed until someone asks why half the imported list has no company data.
Format mismatches cause a fourth, subtler failure. Enrichment APIs return values like an employee count band or an industry string in whatever shape the vendor uses, which will not always match a Pipedrive field configured as a number or a fixed dropdown option. Without explicit mapping and validation on the way in, that write either errors out silently or gets coerced into something meaningless, and the field looks populated even though the value is wrong.
Choosing Clearbit or Lusha for the Right Data Gap
Clearbit’s enrichment works by matching a company domain, extracted from the contact’s email address, against its own database. That makes it strong for firmographic and technographic detail: employee count bands, an estimated revenue range, an industry classification, and detected tools in a company’s stack. Its accuracy depends entirely on having a usable corporate domain to match against. A contact who signs up with a gmail, outlook, or icloud address gives Clearbit nothing to work with, and the lookup returns an empty result. A workflow that logs that as “enrichment failed” rather than “wrong provider for this contact” will keep retrying a lookup that was never going to succeed.
Lusha resolves from a different starting point: name and company rather than domain, which is why it can still return a result for a contact Clearbit could not match at all. Its strength is at the contact level rather than the company level, surfacing direct dial numbers and verified personal emails rather than firmographic detail.
The practical consequence is a genuine waterfall rather than two independent lookups fired at the same contact. Business domain leads should route through Clearbit first for firmographics, then Lusha for the phone and email detail, because that order gives you the company context you need before you spend a contact level lookup. Personal domain leads should skip Clearbit entirely and go straight to Lusha’s name and company search, since Clearbit has no domain to match against and calling it anyway is a wasted lookup on every single one of those contacts.
Building the Enrichment Pipeline in n8n
Once you know which provider should run and in what order, the workflow itself is a fairly compact n8n build: a trigger, a domain check, a branch, and a write back. Whether it survives contact with real production data comes down to how each of those four pieces is configured, not whether the build exists at all.
Trigger and Deduplication Logic
Use Pipedrive’s webhook trigger, available in n8n as a dedicated Pipedrive Trigger node (see n8n’s own documentation for the available trigger events at docs.n8n.io), listening on person added and person updated events. The danger is self-inflicted: because the enrichment workflow itself writes fields back onto the same person record, that write generates its own person updated webhook, and without a guard the workflow triggers itself again, burning API credits on a loop nobody intended.
The fix is a marker field checked at the very start of the run: an “Enrichment Source” custom field that gets set once enrichment completes, so any later trigger sees it is already populated and exits immediately rather than re-running the lookup. It also helps to filter the trigger itself so it only fires on creation, or on changes to the email or company fields specifically, rather than on every field edit a rep makes during a call.
Waterfall Enrichment Sequencing
An IF node checks the contact’s email domain against a maintained list of common personal domains. Business domain contacts branch into an HTTP Request node calling Clearbit’s Company API, followed by a Lusha contact lookup using the company name Clearbit returned. Personal domain contacts skip the Clearbit call entirely and go straight into a Lusha name and company search. Both branches converge on the same write back step.
Writing Back to Pipedrive Without Overwriting Manual Edits
A rep finishes a call, corrects a contact’s job title in Pipedrive because the enrichment guess was wrong, and moves on. A re-enrichment run then does an unconditional write and puts the wrong title straight back. This is one of the fastest ways to lose a sales team’s trust in an automation, because the failure looks like the workflow is actively undoing their work.
The fix is to check the current field value before writing and only fill it if it is blank, or to write enrichment output into separate fields such as “Clearbit Job Title” and let a single computed field decide precedence, keeping the rep’s manual entry authoritative over the vendor guess. Tagging each written field with its source in a hidden custom field also matters: when a number does turn out to be wrong, whoever is auditing it can tell at a glance whether it came from Clearbit, Lusha, or a person, rather than guessing. Pipedrive’s object and field structure, useful if you want to see exactly what a webhook payload contains, is documented at developers.pipedrive.com.
Handling Failures, Rate Limits and Cost Control
Not every non-success response means the same thing, and treating them all identically is a common source of both wasted spend and permanently broken records. A 200 response with an empty match genuinely means the provider has no data for that contact and should not be retried. A 429 means you are rate limited and should be retried after a delay. A 5xx means the provider had a transient error and is also worth retrying. A 401 or 403 means a credential or plan problem that a retry will never fix and should alert a person instead of looping silently.
n8n’s retry-on-fail setting combined with a Wait node gives you exponential backoff on the 429 and 5xx cases specifically, rather than a blanket retry policy applied to every failure type. For bulk imports, running contacts through a Split In Batches node with a short delay between batches prevents the burst of simultaneous calls that trips the rate limit in the first place, which is a more reliable fix than retrying after the fact.
Cost control needs its own logic, separate from error handling. Enrichment vendors typically bill per lookup or per matched record, so a workflow that re-enriches a contact on every field change will burn through budget quickly. A recency check before allowing a second lookup, combined with a running counter that posts a Slack alert once a monthly threshold is approached, keeps the spend visible before it turns into a surprise invoice rather than after.
Staying GDPR Compliant When Enriching Contact Data
Enrichment involves processing a person’s data (a direct phone number, a personal email address, a job title) that was sourced from a third party rather than given to you directly by the contact, and that puts the activity squarely inside UK GDPR obligations regardless of whether the data arrived via Clearbit or Lusha rather than a form fill.
The lawful basis is typically legitimate interests rather than consent, since the contact has not opted in to enrichment specifically. That requires documenting a legitimate interest assessment, weighing your business need against the impact on the individual, rather than assuming enrichment is automatically fine because the relationship is business to business. The Information Commissioner’s Office sets out what organisations are expected to have in place at ico.org.uk/for-organisations.
Data minimisation matters here in a very concrete way: pull only the fields the sales process actually uses for scoring or routing. Requesting every field a vendor’s API offers, on the basis that it might be useful later, works against the minimisation principle and expands what you would need to justify if a contact later asks what data you hold on them or objects to its use. It is also worth checking each vendor’s data processing terms before connecting them into a live workflow, since responsibility for how the underlying data was originally sourced sits partly with Clearbit or Lusha and partly with you as the organisation choosing to use it. A suppression list that excludes contacts who object or unsubscribe from future re-enrichment runs, not only future email sends, closes the loop.
Measuring Whether Enrichment Is Actually Working
A workflow can run without errors and still be failing at its job. Match rate, the percentage of lookups that return usable data, needs to be tracked separately per provider and per domain type, because a personal domain leaning source can complete every run “successfully” while returning empty results for most of its contacts, and that only shows up if match rate is measured on its own rather than read off a generic success or failure count.
Fill rate per field matters just as much, since a lookup can succeed while only populating a company name and leaving the fields that actually feed scoring untouched. Comparing speed to lead and connect rate for enriched versus non-enriched contacts over the same period gives a far more honest read on whether the pipeline is changing outcomes than trusting the workflow’s own completion log. This is also why sync error rates are worth tracking as their own metric, separate from lookup success: Equanax’s automation rebuilds have delivered results such as an 86 percent reduction in fixable sync errors, and a gain in that category only becomes visible if write back failures are measured specifically rather than folded into overall workflow uptime.
Frequently Asked Questions
Does Clearbit work for leads who sign up with a personal email address?
No, not directly. Clearbit matches on a company domain extracted from the contact’s email, so a gmail, outlook, or icloud address gives it nothing to match against and the lookup returns empty. Route those contacts to Lusha’s name and company search instead, rather than retrying Clearbit.
Why would enrichment overwrite a job title a sales rep just corrected by hand?
Because the write back step performs an unconditional update rather than checking whether the field already holds a value. Fix it by only writing to blank fields, or by writing enrichment results into separate tagged fields and letting the rep’s manual entry take precedence.
What causes an enrichment workflow to trigger itself repeatedly?
The workflow’s own write back to a Pipedrive contact fires another person updated webhook, which re-triggers the same workflow. A marker field, checked and exited on at the start of the run once enrichment has completed, stops the loop.
Do we need a contact’s consent before enriching their record with Clearbit or Lusha?
Usually not consent specifically. The typical lawful basis is legitimate interests, which requires a documented legitimate interest assessment rather than an assumption that B2B data is automatically exempt. Data minimisation and a suppression list for objections still apply regardless of the basis used.
How can we tell if enrichment is actually improving pipeline quality, not just filling fields?
Track match rate and fill rate per field and per provider rather than trusting the workflow’s completion log, and compare speed to lead and connect rate between enriched and non-enriched cohorts over the same period.
Related Reading
For more on this, see our automation and n8n coverage, including Building Self-Healing CRM Workflows with n8n for Error Detection and Recovery, How to Automate Quote-to-Contract Workflows with Pipedrive, PandaDoc & n8n, and Automating CRM Enrichment with n8n and ZoomInfo for B2B Growth.
Leave a Reply