Merging Company or Contacts Forces New Record ID for Resulting Object

[James-Preseem]

Hi All, 

Perhaps I am just overly sensitive about these sorts of things.  It is possible that I am overreacting....but I don't think so.

For the past 4+ years, merging companies together involved selecting a primary company and a company to be merged into the primary company.

The merged company would go away and the primary company would stay.   

I wasn't really in love with how conflict resolution between properties occurred....but I am paranoid so whenever I merged companies I would take an all properties export before and after to make sure that the properties that were there in the final merged company were what I expected. 

I recently noticed a series pf problems some of our integrated systems that are built around the record ID of the company.  I went to my colleagues and asked what they had done differently.  Nothing out of the oridinary.

I contacted support....And he good old HubSpot AI bot, replied with the details of the exact functionality that I have always known and understood. 

I understand you're noticing that merging two company records results in a new HubSpot ID for the merged company. Here’s how the process works:

1. When you merge two companies, one is chosen as the "primary."
2. The merged company record keeps the primary company’s HubSpot ID.
3. If it appears as a new HubSpot ID, it's likely that the company you viewed after merging was not the primary, and what you see is actually the primary company's existing ID.

Hmm...so having discussed this with a real human being, I was provided a link to a developer update.

https://developers.hubspot.com/changelog/updated-merge-functionality-for-crm-objects-including-conta...

For those of you who haven't seen this yet...

What happens when I merge records?

When you merge records, the following will occur by default:

• Record ID: a new unique Record ID is created for the resulting merged record. The original Record ID values will still point to the new merged record, so searching records with the original Record ID values will return the new one.

Incidentally the original record ID pointing back to the original record don't currently work with HubSpot search, but I digress.

What if you are using the record id for the company as an ID in a downstream integration....like a billing system or some other SAAS application that pulls data from HubSpot based on the ID?  

I am curious if anyone else has any opinions on this.  For me this was not well thought out.   At the very least this is going to change how we manage duplicate records that HubSpot seems to automatically create for any number of reasons.  Change meaning that we will have to do a tremendous amount of manual reassociation of records (Deal, tickets, contacts, conversations) rather than using the merge functionality.   

On the other hand, we will likely have to unexpectedly revisit several integrations that we have with HubSpot.  Essentially the company record id can no longer be seen as a fixed id.  This change has made it dynamic and who knows what unexpected problems can occur as a result of this.

And all of that assumes that everything that gets merged is merged correctly.  Heaven forbid if you merge two companies together unexpectedly....the potential for privacy problems goes off the chart really quickly.

This "updated functionality" seems like something that was done to make something easier from a development point of view.  I say that because it sure wasn't done to make it any easier for the end user and administrators that work in this product every day.

Thoughts?

James Roberts 

[James-Preseem]

Once again, HubSpot product management or engineering or both make a decision without really understanding the use case for the thing they are breaking.   This is not the first and I am sure it won't be the last time.

[LKruse]

Hi Community, 

Bad for our integration as well. It breaks the sync we have with our POS. It will take significant development work to recognize a new record id. I sent out an edict to my network (150 portals) not to merge records. I'd like to hear why this changed.

[esteeratliff]

Thank you for posting this! Changes like these need to be screamed from the rooftops from HubSpot. I thought I was losing my mind when my integrations started coming back with so many errors out of nowhere for things that have worked perfectly before. It took me a second to figure out why. The ONE saving grace I have found is that if I type in the URL of what the record ID USED to be, it does auto-redirect me to the new "merged" ID #/record.That was my saving grace for figuring out if I was really losing my mind. This required a complete process change for us & at some point, I'll need to do cleanup on all the records I merged without realizing this was happening behind the scenes. It does also help that property history shows what the sub-record ID was, what the master-record ID was, and what the new record ID is. So reporting on the ones I have "missed" updating can be done at some point. Frustrating indeed. I do not believe it's best practices for merging records to change the master record ID. That is a huge structural change and needed to be better announced. 

[Victor_Becerra]

Hi @esteeratliff 

Thank you for your feedback.

I would highly recommend you to please post these product suggestions on the ideas forum.

Our product team, who monitors the forum regularly, can read your specific use case and understand why this would be a useful functionality or change.

It also helps other customers facing the same issue to advocate for its implementation on your behalf by upvoting on the thread as well.

Thank you,

Victor

[JGillan7]

Fully agree, keeping the record id is crucial. 

[HybitHi]

@James-Preseem 

I agree that changing the Record ID on merge is a poor design decision.

Could you briefly describe the scenarios where it fails for you?



When I test the merging Contact records, I can indeed read and update (via https://api.hubapi.com/crm/v3/objects/contacts/) the newly merged record using the Record ID of either of the merged records.

So, if syncing from $System TO HubSpot, the pre-merge Record ID in $System should still update the correct record.

Does the issue arise when syncing FROM HubSpot to $System (triggered by a webhook, for example) because the incoming Record ID no longer matches the Record ID in $System?

[BérangèreL]

Hi @James-Preseem,

Thanks for reaching out to the HubSpot Community!

I'm sorry to hear about your experience regarding this.

I would like to apologize for the frustration, data issues, and business impact this has caused.

I'd recommend that you share this valuable feedback on the "Developer Feedback form".

Yes, the documentations have been updated accordingly. Here is another article about this "What happens when I merge records?":

"Record ID: a new unique Record ID is created for the resulting merged record. The original Record ID values will still point to the new merged record, so searching records with the original Record ID values will return the new one."

Please let me know if there is anything else I can help with. I'll be delighted to do so!

Have a nice day!
Bérangère

[James-Preseem]

Hi Bérangère

Thank you for your reply.   I will certainly cross post this in the developer feedback forum as well.

I am aware of the article you posted.  It does describe functionality that I believe is currently broken....i.e. "searching records with the original Record ID values will return the new one" Does not currently work...and that is a big deal.

Fundamentally, If merging an account creates a new ID for a given customer and you can't find the customer using the previous ID....and you have a systems that depend on the old ID....that represents a major problem.

Thanks

James

[XRoy]

Hi all,

I fully agree with you @James-Preseem.

@BérangèreL, we have the exact same issue at the Canadian Chamber of Commerce with one of our integrations between HubSpot and our accounting software, which relies on the Record Id value to match with transaction history in our accounting software.

Thank you,

Xavier