From Inbound Email to a Fully Enriched Pipedrive Deal with n8n

Two AI workflows that turn raw lead emails into structured CRM records researched, scored, audited, and ready for the sales team.

The problem: A CRM that waits for someone with time

A Pipedrive record only becomes useful once a human has finished filling it in and that step is exactly where the pipeline stalls. An inbound lead email arrives. Someone has to read it, decide who the person and organization are, search Pipedrive for duplicates, create what is missing, judge whether the lead is worth a call, and write a briefing for the rep who gets assigned. Days later, someone else circles back and tries to plug the empty fields industry, headcount, country, LinkedIn URL by Googling the company.

None of those steps is hard on its own. Across hundreds of leads a quarter, the costs compound in ways the sales pipeline feels directly:

• The inbox becomes a queue - leads sit unread until a rep clears the backlog. On busy weeks, that backlog runs into days.
• Qualification is a coin flip - the rep who happens to open the email is also the one judging whether the deal is worth pursuing. Two reps will not arrive at the same answer.
• Records arrive empty and stay empty - a Person or Organization gets created with a name and not much else, then waits weeks for someone to fill in the rest. Reports built on that data drift quietly.
• Research happens by accident - one rep tracks down the LinkedIn profile, another does not. There is no rule that says every record gets a baseline of structured context.
• Nothing is auditable - when a field is filled in, there is no record of who put the value there, what URL backed it up, or how confident they were.

We wanted to remove every one of those steps. The bar was specific: an inbound email should produce a fully populated Pipedrive deal in seconds, every enriched field should carry the URL it came from and a confidence score, and a human should only get involved when something genuinely needs a second opinion.

Two workflows, one pipeline

The system is two independent n8n workflows that happen to call each other. The first reads inbound lead emails and turns them into Pipedrive deals. The second watches for newly created Person and Organization records in Pipedrive and enriches them against public web data. The hand-off between them is implicit: Pipedrive's own update trigger fires the enrichment workflow whenever the first workflow inserts a record. Neither workflow knows the other exists, which is exactly the property we wanted anyone manually adding a Pipedrive contact gets the same enrichment for free.

Three pieces are worth describing in turn:

1. Inbound email becomes a qualified deal

The workflow runs in three distinct phases. The first phase is intake and validation: an email lands at the configured intake address, a webhook hands the message to n8n, and the workflow verifies that the recipient actually matches the intake mailbox anything else is dropped on the floor before a single CRM record is touched. The body is then normalized, and a tightly scoped OpenAI call (gpt-5-mini with a structured output parser) extracts only the identity signals needed to attach the email to a Person and an Organization. Nothing about the deal itself is inferred at this stage.

The second phase is CRM identity resolution. Parallel branches search Pipedrive for the Organization and the Person, pick the highest-similarity match, or create the entity when no match exists. If neither a usable Person nor a usable Organization can be resolved, the workflow exits on a missing-identifier branch better an unprocessed email than a malformed deal.

The third phase is qualification and deal creation. A second OpenAI call picks up the resolved Person and Organization and produces a structured opportunity check deal title, need summary, urgency, buying signals, risks, missing information, recommended next step, suggested reply angle, scored 0 to 100. That output becomes an HTML-formatted note, the deal is opened in Pipedrive with org_id and person_id populated only when those records actually resolved, and the note is attached. The two-LLM split is deliberate. The first call is told to do nothing but identity extraction. The second call is told to qualify but never to invent identity. Anything one model gets wrong stays bounded to its own job.

2. Every new entity enriches itself

The enrichment workflow has two triggers but a single shared pipeline. A Pipedrive Person update trigger and a Pipedrive Organization update trigger both feed the same normalization step, which emits a common payload of entityType, entityId, known_fields, and missing_fields. The workflow validates the event, fetches the current entity from Pipedrive (so it reasons over fresh CRM state, not the webhook delta), and decides whether enrichment is even needed. If every supported field is already populated, the run exits cleanly without an OpenAI call.

The supported fields are deliberately constrained we only enrich what we know how to validate:

| Entity | Enriched Fields | | ------------ | -------------------------------------------------------------------------------------------------------- | | Person | first_name, last_name, email, phone_number, position, linkedin_person | | Organization | company_name, website, linkedin_company, industry, company_size, hq_country, revenue_funding, email |

When fields are missing, the workflow calls an OpenAI response node with web search enabled. The model receives known_fields only to identify the entity and may return values only for fields listed in missing_fields. Three of the organization fields industry, company_size, revenue_funding are constrained to controlled vocabularies that map back to Pipedrive enum option IDs. Every field returned carries three things: the value, the public source URL where it was found, and a confidence score of high, medium, or low.

After validation, the workflow refetches the entity from Pipedrive immediately before the write, so any field a human typed in mid-flow is respected. The update payload includes only fields that are still empty; existing values are skipped with a skipped_existing status. If any updated field came back at low confidence the workflow attaches an Enrichment: Review Needed label, otherwise it attaches Enrichment: Enriched. A Pipedrive note describes exactly which fields were updated and which need a second look. In parallel, an audit row is written to Baserow with one column per {field}_value, {field}_source, {field}_confidence, {field}_status plus the entity ID, the Pipedrive name at the time of processing, and the enrichment label action.

3. The chain, end to end

Consider a real inbound email used during testing: a short message from [email protected] describing AAI-Labs' interest in lead intake and CRM automation, asking to schedule a call.

Workflow 1 validates the recipient and extracts identity: Person Andrius Tamulevicius, Organization AAI-Labs. Neither record exists, so both are created. The sales opportunity check returns a score of 82/100, fit "Strong fit", urgency "medium", a list of buying signals, and a list of risks (no budget stated, decision-making authority not provided, no implementation deadline). Workflow 1 then opens the deal AAI-Labs - Lead intake and CRM automation, links the new Person and Organization, and attaches the Sales Opportunity Check note.

Creating the AAI-Labs organization in Pipedrive fires Workflow 2. The organization arrives with only a name; the workflow identifies seven of eight supported fields as missing and dispatches the enrichment call. The model returns website https://www.aai-labs.com/ (high), LinkedIn https://lt.linkedin.com/company/aai-labs (high), industry "Technology, information and media" (medium), company size "51-200" (high, mapped to employee_count: 125), HQ country "Lithuania" (high), and email [email protected] (high). Revenue funding comes back null because no public source supports it. The workflow refetches the organization, confirms each target field is still empty, writes the update, applies the Enrichment: Enriched label, drops a note, and stores an audit row in Baserow.

Person enrichment is more conservative. In a separate test, a record was created with Name Tadas Šubonis and Organization AAI-Labs the workflow matched and enriched Aistis Raudys with email [email protected] (high), LinkedIn https://www.linkedin.com/in/aistis-raudys-80497b6 (high), and Position "CEO" (low). Because Position came back at low confidence, the Enrichment: Review Needed label was applied and the note explicitly flagged Position as one to double-check.

From the moment the email hit the intake address to the moment every record was enriched, audited, and linked, no one touched a keyboard.

How the writes actually happen

The deal creation workflow is roughly twenty nodes across three phases; the enrichment workflow is twenty-eight nodes split between a shared pipeline and entity-specific write branches. A few moments in that wiring are worth a closer look they are where most of the safety properties live.

Identity extraction - gpt-5-mini with a structured output parser pulls only person and organization identity from the validated email. The system prompt forbids deal extraction at this stage, requires unknown fields to be returned as empty strings, and rejects generic email domains (gmail.com, outlook.com, proton.me) as organization domains unless the email body explicitly says so.

Pipedrive resolution and deal creation - Parallel branches search Pipedrive for the Person and Organization, pick the highest-similarity match, or create the entity when none is found. A second OpenAI call then runs the sales opportunity check against the resolved CRM context. The deal is created with org_id and person_id populated only when those records actually resolved preventing invalid empty CRM IDs.

Enrichment with web search - A GPT-5.2 response node with web search enabled is constrained to research only missing_fields and to return the fixed JSON shape { entityType, results: { <field>: { value, source, confidence } }, unresolved_fields: [] }. Field-specific rules in the system prompt prevent common failure modes only canonical company URLs for website, only LinkedIn URLs that belong to the matched entity, only industry values from the allowed list.

Validation, refetch, write - A code node parses the response, strips any markdown fences, validates that every requested field appears in the result, and rejects controlled-vocabulary values that fall outside the accepted lists. The entity is refetched from Pipedrive immediately before the update payload is built, and only fields still empty in the refetched record are written. Email and phone updates merge into Pipedrive's labeled arrays rather than overwriting them.

Audit logging - Every run produces a Baserow row with a column per {field}_value, {field}_source, {field}_confidence, {field}_status. The status values track exactly what happened to each field updated, updated_new, updated_merged, skipped_existing, skipped_no_value, skipped_no_mapping, or unresolved.

What this looks like in the day-to-day

Both workflows have been the default path for inbound lead handling since deployment.

• A lead email is a deal before anyone reads it - by the time a rep opens Pipedrive in the morning, every email that came in overnight is already an open deal linked to a real Person and Organization.
• Reps walk into calls already briefed - the Sales Opportunity Check note on each deal sets out fit, urgency, buying signals, risks, and a suggested reply angle without anyone having to write it.
• No more half-empty contact cards - a Person or Organization record never lives in Pipedrive with just a name; the enrichment fires the moment it is created, whether the source was inbound mail or a manual entry.
• Every value can defend itself - the source URL and confidence score sit next to the field, so a rep who notices something off can tell at a glance where it came from.
• Low-confidence updates ask for a second look - records with any low-confidence field carry an Enrichment: Review Needed label; the rest carry Enrichment: Enriched and can be taken at face value.
• History does not live inside Pipedrive - Baserow holds a permanent per-run record of what was changed, what was skipped, and why, even if someone later edits the Pipedrive record by hand.

Threads we are still pulling on

The system covers the core path, but there are a handful of follow-ups already on the list:

• Smarter person disambiguation - combining email domain, organization, and name when the LLM is working from thin signals. We see occasional confident matches built on weaker evidence than we would prefer.
• Tighter LinkedIn sourcing - LinkedIn URLs come from web search rather than the LinkedIn API, so quality follows whatever the search ranks first. Constraining sources further would shrink the long tail of low-confidence Position results.
• Audit logging for the deal workflow - the enrichment workflow already writes every run to Baserow. The deal-creation workflow does not, beyond the deal and note it leaves inside Pipedrive. A matching audit table for deals would close the loop.
• A holding pen for ambiguous emails - today the deal workflow halts safely when neither a Person nor an Organization can be identified. A dedicated review queue would surface those without cluttering the deal board.
• Continued prompt iteration - both LLM prompts keep moving as we watch where the model goes wrong on real mail.

What we will keep doing

The hard part of CRM is not Pipedrive. It is the time between an email landing and someone turning it into a structured record the gap where leads go cold, fields stay empty, and qualification waits on a calendar. Native CRM tools cannot close that gap on their own because the work is half judgment (is this lead worth the call?) and half research (where does this company live, who runs it, how big are they?). Both used to need a person at a keyboard.

A few design choices made the difference and we will keep them on every project that touches a system of record. Enrich only what is missing never touch a field a human has already filled. Refetch the source of truth immediately before any write, so the workflow loses any race against a human editing the same record. Keep the source URL and the confidence score next to every value, because a number without provenance is just a guess in a database. Constrain the model to controlled vocabularies the moment the destination expects an enum. And let creation events trigger their own enrichment, so the system fills itself in by default rather than waiting for someone to remember it has work to do.