We have a 2 way sync between Hubspot and Salesforce where workflows create either Salesforce Leads or Opportunities depending on whether the contact already exists in Salesforce.
The team want to explore creating all MQLs as Salesforce Leads regardless of whether the contact exists in Salesforce or not. I have a number of concerns around moving from a one-to-one relationship from the Hubspot Contact to Salesforce Lead/Contact to a one-to-many relationship (contacts can and do create multiple MQLs). For example, we use fields on the Hubspot Contact record to curate dynamic lists where the data originates in many cases from Salesforce. How would the sync relate to multiple records Salesforce Contact/Lead records feeding back in to the same singular Hubspot Contact record?
Has anyone attempted, experienced or explored creating everything as Salesforce Leads before?
Has anyone experienced or explored this before? Are there any other implications we should factor in that we should discuss? Or is there an alternative solution that we should consider?
Great question to bring to the community! This type of architectural decision is definitely worth investigating before committing to anything.
I’m going to tag in a few folks from the community as I believe hands-on experience will be the most helpful here. Though in the meantime, here are few resources that might help frame the conversation:
Hey @danmoyle, @lnorden, @CarolinaDeMares do you have any experience with this? If so, are you able to share any insights you have on this process or suggest another?
I haven’t personally worked with this exact Salesforce setup, so I’ll defer to anyone here with more hands-on experience, but one thing that immediately jumps out to me is the record matching/sync behavior.
Salesforce allows multiple Lead/Contact records with the same email address, while HubSpot does not. HubSpot’s documentation states that when multiple Salesforce records share an email, HubSpot can end up syncing with whichever Salesforce record was most recently updated, giving you zero control over where the Data lands within Salesforce.
If one HubSpot Contact is tied to multiple Salesforce Lead/Contact records, I’d be concerned about which Salesforce record becomes the source for those mapped fields and whether values could overwrite each other as different records are updated.
Because of that, I’d be hesitant to use separate Salesforce Lead records to represent each MQL. Just based on what I know about HubSpot, I would consider keeping the person-level relationship 1:1 and representing the repeat MQL activity through another object/process instead.
But again, I haven’t implemented this particular setup, so I am not positive but I definitely think your concern around moving from 1:1 to 1:many is worth digging into before making the change!
Hopefully that helps, I’m interested to know how you end up moving forward!
Hey @JManx. Really interesting use case here. Like @lnorden I haven’t been asked to do exactly what you’re describing. But with that said, based on how I’ve helped clients set up their SFDC <> HS syncs over the years, I’d say you’re right to pause on this one. I wouldn’t use multiple Salesforce Leads to model repeat MQL events for the same person.
As others point out, the HubSpot to Salesforce sync is built around one HubSpot contact, matched by email, syncing to one Salesforce record. When Salesforce has more than one Lead or Contact matching that email, HubSpot can’t reliably pick the right one. It’ll sync with whichever record was updated most recently, which means fields like lead status, owner, and qualification data can start reflecting the wrong MQL event instead of the current one.
That’s a real problem for your dynamic lists. Property history gets muddy, conversions get messy when one Lead converts and others don’t, and you lose the clean link between your HubSpot contact and the correct Salesforce person.
I’d treat each MQL as an event, not a new person. Keep the 1:1 contact sync intact, and store repeat qualifications somewhere else, whether that’s a custom object like MQL Event, a Salesforce Campaign Member status, or a controlled field on the contact that a Salesforce Flow picks up to trigger the right downstream action (task, campaign update, new opportunity, etc.).
Ask yourself what’s actually new here: a new person, a new qualification event, a new follow-up, or a new deal. Those are four different things, and only the first one calls for a Lead.
Thank you @danmoyle. I had my concerns around duplicates, unpredictable sync activity and polluted data but I don’t count myself as an expert when it comes to HubSpot so I appreciate getting this feedback from those with more experience, like yourself and @lnorden, that I can take back to the team for assessment.
I understand this set up is discouraged by HubSpot, achievable but problematic with Marketo where Pardot does a better job than handling this scenario than the rest (albeit not without issues).
The problem we’re trying to solve creating records in Salesforce when maybe the enquirer needs further nurturing before being handled by the sales team (employing an SDR is on the table to bridge that gap between cold Salesforce Lead and warn Salesforce Opportunity).
I also don’t think we’re utilising HS to anywhere nears its full capacity. If anyone has any use cases or best practice articles I could take to the team about how best to manage this top of funnel pipeline (without and SDR) then I would be interested to read/hear them.
Context: Currently are pipeline is:
Form Submission > Ticket Creation in HS > Qualify Ticket in HS > HS Workflow Creates either SF Lead or Opp
Following this thread with interest — the record-matching concern lnorden raised (which Salesforce record becomes the source of truth) is exactly the kind of HubSpot/Salesforce field and data-integrity mismatch I’ve been looking into. Did you end up finding a clean way to handle it, or is this still unresolved for you?