I am facing a contact issue merge issue between HubSpot and Microsoft Dynamics 365.
The Scenario is that our customers have Microsoft Dynamics 365 integrated with Hubspot and they did a contact sync on Hubspot, if records are same, they merge Dynamic lead and Hubspot contact together, customer also integrates Hubspot and Dynamics with us, finally we end up with two separate records for the same person in our database:
Record A (lead in Dynamics): Ingested via Dynamics 365 API (Primary Key: Dynamics GUID).
Record B (contact in Hubspot): Ingested via HubSpot API (Primary Key: HubSpot Object ID).
The Goal is that we want to implement a logic in our backend to merge the HubSpot contact record (Record B) into the Dynamics lead record (Record A) automatically by looking up the Dynamics GUID stored within the HubSpot contact properties. I need exact field name of the HubSpot properties that store these Dynamics GUIDs to use as foreign keys for matching.
For Hubspot contact, I found a property named crm_lead_id, which appears to store the Dynamics lead GUID. Can someone help confirm this is the standard field that I can use for matching?
If yes and the record in Dynamics is a contact (not a lead), does HubSpot store the GUID in crm_contact_id as well?
If no, is there any other way to know the field name that I can used for detecting duplicated records between these 2 system.
Hi @LZhao and great question, thanks for asking the HubSpot Community!
I understand that you are using the “Microsoft Dynamics 365” integration and you’d like to know what is the exact HubSpot contact property field name that stores the Dynamics 365 GUID. Please let me know if that’s not the case.
Let’s consult our Top Experts: Hi @Brenner, @Mike_Eastwood and @IFarafonov do you have suggestions to help @LZhao, please?
Thanks so much and have a lovely day!
Bérangère
‘you’d like to know what is the exact HubSpot contact property field name that stores the Dynamics 365 GUID’
yes, because I found there is a field called crm_lead_id in hubspot contact, seems this is not a standard field in hubspot, so I am not sure there are some standard fields can store Dynamics 365 GUID.
Yes — when using the native HubSpot ↔ Dynamics integration, crm_lead_id and crm_contact_id are the standard properties HubSpot uses to store the Dynamics GUIDs (lead vs contact). Those are the correct fields to use for matching. If those aren’t populated, then the integration wasn’t the one that created/synced the record, and you’ll need to rely on email or a custom external ID instead.
thanks for answering, my next question is there a way for customers to unintegrate Hubspot and Dynamics, if customer can do this then crm_lead_id and crm_contact_id will become empty?
could you help take a look at my second quesiton here? Is there a way for customers to unintegrate Hubspot and Dynamics, if customer can do this then crm_lead_id and crm_contact_id will become empty?
Hi @LZhao
Good question and @thismarkjohnson is correct about the field names. When using the native HubSpot Dynamics integration, crm_lead_id stores the Dynamics lead GUID and crm_contact_id stores the Dynamics contact GUID. These are created by the integration and are the right fields to use for matching.
To answer your follow up question: yes, customers can disconnect the integration, but the GUID values in those fields typically persist even after uninstalling. HubSpot doesnt automatically clear property values when an integration is removed. However, you shouldnt rely on this behavior being guaranteed. If someone manually clears those fields or if theres some cleanup process, you’d lose your matching keys.
A more robust approach for your backend logic would be to use email as a fallback matching key when the GUID fields are empty. Email is usually the most reliable cross system identifier. You could also consider storing a copy of the Dynamics GUID in a custom property that you control, so it wont be affected by integration changes.
One thing to watch out for: the native integration has limitations around complex sync scenarios, especially when records exist in both systems before integration or when you need bidirectional updates.
Hope that clarifies things. Let me know if you have more questions about the matching logic.