Retain Primary Record ID During Merges to Preserve Integrations and External References

[Anders_B]

Hi HubSpot Team and Community,

We're encountering a significant challenge with how record merges handle IDs in HubSpot, particularly for Companies (though this applies to other objects like Contacts and Deals). When merging duplicates, HubSpot generates an entirely new Record ID for the resulting merged entity, rather than retaining the ID of the designated primary record. This behavior disrupts our workflows and integrations in several ways.

Context and Problem:

• In our setup, we rely on HubSpot Record IDs as unique references for syncing data with external systems (e.g., via Zapier, custom APIs).
• For example, when merging duplicate Companies, we select a primary record with the most accurate data and associations. However, post-merge, the new ID replaces the original, breaking any external links or references tied to the old ID.
• This forces manual updates across systems, leading to data inconsistencies and potential errors in automated processes.

Impact on Our Operations:

• Integrations Breakage: External tools and databases that query HubSpot by Record ID (e.g., for customer identification or reporting) fail after merges, requiring rework and risking data loss.
• Efficiency Loss: With a small sales team, we prioritize simple processes. This ID change complicates data migration from our previous CRM (Freshsales) and ongoing syncs, adding unnecessary admin overhead.
• Scalability Issues: As we grow our HubSpot usage for sales and marketing, frequent merges (e.g., during data cleanup) amplify this problem, affecting workflows, automations, and third-party connections.

Proposed Feature/Improvement:

• Allow users to retain the Record ID of the primary record during merges. The merged data (properties, associations, activities) would consolidate under the primary's existing ID.
• This is standard behavior in other CRMs like Salesforce, Freshsales, and Zoho, where the primary ID persists to maintain continuity.
• Optional: Provide a toggle or warning during merge to choose ID retention, with redirects/aliases for secondary IDs to avoid broken links.

This change would align HubSpot with best practices for data integrity in integrated environments, making it easier for teams like ours to maintain clean, referenceable data without disruptions.

Would love to hear if others are facing this or have workarounds. Thanks for considering!

[CAltmann]

I agree with the above - since merging causes a new record ID to be created its started causing major headaches for our integrations accross the business, as records are then no longer kept in sync. This is a serious issue that i cant beleive HubSpot didnt take into account. 

Alternativly, HubSpot should provide the ability to not allow merges for roles so admins can maintain data integrity and only do merges that are not going to effect other systems in an organization. 

[CMenikheim]

We also used the record id as the "key" to reference the same customer across multiple systems. This update to the way merging works causes multiple down-stream problems. I would much prefer to revert to the older system of being able to determine which Record ID to keep as the "primary" property.

Some references of others having the same issue:

@James-Preseem , @esteeratliff , @JGillan7 , and @XRoy -

https://community.hubspot.com/t5/CRM/Merging-Company-or-Contacts-Forces-New-Record-ID-for-Resulting/...

@ChrisDellen - https://community.hubspot.com/t5/CRM/Merged-Records-Creating-New-Record-IDs/m-p/1189392/thread-id/15...

[esteeratliff]

yup, this is still a big headache for our integrations. I now have workarounds for 75% of our records. The other 25% do update on their own, thanks to my integrations support teams jumping in. We'd have to change our setup to get the other 75% to work automatically and I really dont want to modify something that was working so perfectly. 😑

[James-Preseem]

The HubSpot defense of this change is that if query the old ID via the API, you "should" still get the new results from new merged object.  Not something that made me especially comfortable to be honest.

In most cases when a rogue object appears like a new company with that is a duplicate or a contact that is a duplicate.  I tend to re-associate all of the relevant information with the existing object and simply delete the new one rather than incurring the fall out from this new merge "Feature".

[CSaß]

I completely agree. We had almost resigned ourselves to the problem and decided that we would no longer merge data records but instead build a process to transfer the relevant information and then delete the data record. The main problem for us is also that the company and contact IDs are transferred to our product backend, because API calls are made from there to check whether there are any active deals assigned, etc. Of course, the direct API calls still run smoothly, as they are automatically rerouted to the correct data record, but it no longer works for debugging problems and also for API calls to the Search API (deals assigned to this object). Our product developers were shocked when the behavior of the merges changed, as in these circles an ID is clearly an unchangeable value. No one can understand how anyone could have come up with such an idea. Now there is another problem since we joined the HubSpot Helpdesk with Zendesk customer service:

If an unknown contact starts a chat and then enters their email address, an unknown contact record is suddenly merged with the existing record. This, of course, immediately changes the ID again, and the customer can no longer access our product. We had almost resigned ourselves to this and thought we would create a workflow that would notify our product when the record ID changed, which record ID had to be replaced by which one. The problem: since it is a new record, I have no history in the record ID. Unfortunately, however, particularly unfavorable things happen in the merged IDs property. I tested it myself:

I created three records and actually wanted to test whether the ID of the last original record before the merge always appears at a certain point in the sequence. But what I found out was that even record IDs are lost: