Lead Handoff from HubSpot to Salesforce with Governed Enrichment

Marketing captures a contact in HubSpot. Sales works in Salesforce. Somewhere between them, a sync rule decides whether the contact becomes a lead, updates an existing contact or disappears. When those rules are implicit, sales teams find duplicates, missing context and leads assigned to the wrong owner.

The problem is not a missing connection. It is missing governance: no visible deduplication rule, no place for ambiguous cases, and no record of why a lead ended up where it did.

This guide describes a Nexus pattern for the handoff. Nexus provides 69 HubSpot actions across Core, Contacts, Deals, Tickets, Forms, Companies and Email. Additional HubSpot operations can use its API through the HTTP Request node.

HubSpot is not listed among current trigger sources, so the run starts from the webhook receiver, the HTTP poller or a schedule. A webhook suits near-real-time handoff where it is configured. A poller or schedule suits batch handoff with explicit windows.

The first step reads the candidate record through the HubSpot API with the HTTP Request node, under a vault-backed credential, and records the input.

Starting from generic sources is not a workaround. It keeps the trigger explicit and versioned with the workflow.

• 01Webhook receiver, HTTP poller or cron schedule
• 02HubSpot API read through HTTP Request
• 03Input recorded for every run
• 04Credentials held in vault-backed secrets

Rules + Code checks whether the person already exists in Salesforce, using the matching rules your sales operations team agrees. Exact matches update. Clear non-matches proceed to creation. Ambiguous matches pause for review.

Enrichment can add routing information from approved internal sources. If a self-hosted model is used to classify free-text fields, its output is an input to rules, not a final decision.

Every rule is part of the workflow version, so a changed matching rule is visible in history.

Sales operations reviews only the ambiguous cases: possible duplicates, conflicting ownership, incomplete records. The reviewer sees both records and the reason for the pause, and chooses merge, create or discard. The choice is recorded.

This keeps human effort where judgement is needed and gives the organisation a record of how matching decisions were made.

Salesforce appears in the actions library, and AddContactToCampaign is available as a pre-built action, useful when a qualified contact should join a campaign. For lead creation or updates outside the pre-built action groups, use the Salesforce API through the HTTP Request node.

The response, including the Salesforce record reference, is captured. Where useful, the reference is written back to HubSpot through its API so marketing can see the handoff completed. In the reverse direction, contacts that originate elsewhere can be created in HubSpot with the create contact action.

Failures are explicit. A rejected write goes to a reviewer, and the run does not report a handoff that did not happen.

Each handoff records the source record, match result, any reviewer decision, the Salesforce call and response and any write-back. Sales and marketing disputes about lead quality can start from facts.

Nexus runs on-premises, in private or sovereign cloud, or air-gapped. Nexus provides 1,480+ pre-built actions across 43 product families. Additional operations can use APIs, protocols, databases or Rules + Code in the same governed run.

Marketing and sales keep their tools, and the handoff gains rules everyone can read.