HubSpot–Salesforce Bidirectional Sync: Lead Assignment, MQL/SQL Handoff, and Campaign Attribution

When marketing and sales operate in the same revenue operating system, handoffs feel seamless and pipeline moves faster. When they operate in parallel universes, the same lead can be routed twice, ignored entirely, or reported differently by each team. This playbook shows how to structure a bidirectional sync between HubSpot and Salesforce so that lead assignment, MQL/SQL acceptance, and campaign attribution work as one motion—visible, auditable, and fast.

The goal is not to sync every property in both directions. The goal is to connect the events that matter (qualification, acceptance, creation of opportunities, and campaign interactions) and to make them true in both places. We will design the routing logic where it belongs, ensure acceptance is recorded in a single, crisp way, and bind campaign influence to opportunity revenue without double counting.

Alignment Goals

Before mapping fields and building workflows, align on the business outcomes and the truths each system owns. A workable division of responsibility is straightforward:

HubSpot owns qualification events (MQL), nurture, and initial routing intent.
Salesforce owns assignment execution, acceptance/rejection decisions, and creation of opportunities.
Both systems surface campaign interactions and membership, but Salesforce remains the source of truth for influence tied to revenue.

When you align on this division, ambiguity around timing and ownership drops dramatically.

Bidirectional Sync Principles

Bidirectional sync should exist to mirror what the other team needs to see, not to create control collisions. For Contact/Lead profile data (email, name, phone), bidirectional is safe. For sales outcomes (lead status, owner), Salesforce should write and HubSpot should read. For marketing outcomes (MQL, latest source), HubSpot should write and Salesforce should read. For opportunity and campaign membership, Salesforce should write and HubSpot should read.

If you cannot explain the direction and owner of a field in one sentence, don’t sync it both ways. Start one-way, observe, then graduate to bidirectional only where you prove it adds value.

Designing Lead Assignment

The fastest path to better speed-to-lead is to remove guesswork from the routing rules and centralize enforcement. HubSpot does an excellent job at initial determination of the correct queue, segment, or territory using forms, enrichment, and intent data. Salesforce is best at executing ownership and recording acceptance.

Implement the following routing baseline:

Use HubSpot lists and workflows to compute routing decisions and write the intended owner or queue ID into a mirrored field visible in Salesforce.
In Salesforce, a flow reads that intent, applies territory exceptions or round‑robin logic, sets the true owner, and writes a timestamped “Assigned” event.
HubSpot ingests the owner and acceptance outcome and uses them to drive SLAs and handoff analytics.

This design keeps marketing automation expressive while preserving a single execution plane for ownership.

MQL and SQL Handoff

Treat MQL and SQL as state transitions anchored to events, not subjective opinions. HubSpot sets MQL when a person meets defined, published criteria (score, intent, or product signals). Salesforce sets SQL when a human makes a decision to work the lead. The sync’s job is to make those events reflected in both places without lag or ambiguity.

In practice, MQL should cause a Salesforce assignment event (queue or owner) and a required acceptance within your SLO. SQL should trigger HubSpot to move the person to SQL lifecycle and to suppress further inbound routing workflows.

Do not let “SQL” be inferred by arbitrary lead status text that differs per team. Define a single, machine‑readable acceptance property tied to a button, quick action, or flow in Salesforce. Humans click; systems agree.

Campaign Attribution that Survives Audits

Campaign work spreads across both platforms. HubSpot tracks email, ads, website, and forms; Salesforce houses campaigns tied to opportunities. To prevent double counting and misattribution, drive the following agreements:

Sourced pipeline is attributed to the first qualifying campaign touch that led to MQL, not every touch that ever happened.
Influenced pipeline is attributed to the set of campaign memberships on contacts with primary roles on the opportunity, subject to a time window.
All revenue numbers (Closed Won) reconcile back to Salesforce, and any HubSpot reports annotating revenue use mirrored values rather than re‑computed amounts.

These rules let you combine the best of both tools without creating two truths.

Data Model and Properties

Create a compact set of mirrored properties for assignment and acceptance. Keep them boring, auditable, and controlled:

Intended Owner or Queue (HubSpot writes; Salesforce reads).
Actual Owner (Salesforce writes; HubSpot reads).
MQL Timestamp (HubSpot writes; Salesforce reads).
SQL Accepted (boolean) and Acceptance Timestamp (Salesforce writes; HubSpot reads).

This quartet supports handoff dashboards, SLA monitoring, and fast troubleshooting.

Workflows and Flows

HubSpot workflows compute MQL, set intended owner, and write campaign touch annotations. Salesforce flows execute assignment, capture acceptance or rejection with reasons, and create opportunities when appropriate. Both systems should log their actions in human‑readable notes or history fields to make debugging easy.

As you add rules, prefer small, well‑named workflows over one giant “super workflow.” In Salesforce, prefer modular flows with clear entry conditions. The sync does not need to know your entire logic; it only needs to move a handful of fields and timestamps faithfully.

SLAs and Dashboards

Define SLAs that drive behavior, not frustration. Two SLAs matter most: time‑to‑assignment (how quickly the system assigns) and time‑to‑acceptance (how quickly a human accepts or rejects). Instrument both:

In Salesforce, create a report on assignment and acceptance timestamps and segment by source, territory, and campaign.
In HubSpot, build lists that identify MQLs not accepted within the SLO and trigger reminders to owners and managers.

Publish the targets and show them in the same place every week. What is measured improves.

Error Handling and Retries

Assume assignment and acceptance can fail. Build idempotent retries: if an assignment flow fails, try again and log it. If acceptance is not recorded due to a transient error, keep a queue that retries until success or until a human intervenes. Visibility is more important than perfection; a small number of transparent errors are acceptable if no record can fall into a black hole.

Opportunity Creation and Feedback Loop

When SQL acceptance happens, the next milestone is an opportunity. Salesforce owns this event. HubSpot should read opportunity creation, amount, and close date as a mirror. Use that mirror to feed nurture and enablement, not to reconstruct revenue math. If you need to automate nurturing based on deal stage, do so with read‑only signals from Salesforce.

The feedback loop completes when HubSpot sees Closed Won and updates Lifecycle to Customer. At that moment, pause most acquisition nurtures and switch to onboarding/expansion motions.

Documentation and Schema Versioning

Document the field set and event semantics in a living schema file. Version it like code. Whenever you add a field or change directionality, bump the schema version and record why. This practice makes audits painless and cross‑team coordination faster.

Rollout Plan

Do a quiet pilot before a broad go‑live. Start with a single territory or product line. Measure assignment speed, acceptance rate, and conversion to opportunity. Fix the handful of issues you will inevitably find. Then roll out to the whole org with confidence and a published training brief for sales and marketing.

Common Traps to Avoid

Integration problems tend to rhyme. Prevent the common ones:

Using free‑text Lead Status values that vary per rep or team; acceptance should be a single, universal switch.
Allowing HubSpot to overwrite sales decisions; write‑protect outcomes and mirror them instead.
Counting revenue twice by mixing HubSpot attribution revenue with Salesforce Closed Won; choose one source of truth for dollars.

FAQ

How should we route leads that submit multiple forms before acceptance?

Do not reassign on every form. Keep the original intended owner until acceptance or rejection. Use campaigns and activity history to capture the many touches without rerouting.

What’s the best way to capture acceptance in Salesforce?

Use a purpose‑built quick action or button that sets SQL Accepted and stamps the acceptance timestamp. Avoid complex status strings and stick to a binary decision for clarity and reporting.

How do we prevent duplicate assignment rules across systems?

Let HubSpot compute intent and let Salesforce execute ownership. Never duplicate full routing logic in both places; it will drift. Mirror only what’s needed (intended owner, acceptance outcome).

How do we reconcile sourced vs. influenced pipeline?

Publish the rule set and implement in one system (often Salesforce with a BI layer). HubSpot should mirror opportunity revenue for segmentation and nurture, not calculate dollars independently.

What is a reasonable SLO for acceptance?

Many high‑velocity teams start at 24 business hours and tune down to 4–8 hours for inbound demo and high‑intent signals. Set tighter targets for product‑qualified or intent‑rich sources.

How do we handle opportunities created directly by AEs without acceptance?

That’s acceptable if the AE is working the person; treat opportunity creation as implicit acceptance. Your sync should still reflect SQL in HubSpot when an opportunity is created in Salesforce.