We have a lifecycle stage at company level named “Churn” and are tracking it based on the last closed won date (if earlier than 1 year then change the status to Churn via an automation).
The problem we are facing is often we have to merge companies with different lifecycle stages and last closed won dates, and after the merger HubSpot automatically updates these two fields (lifecycle stage and closed won date) with the data from the new company instead of keeping the data as it is (irrespective of if the company is being merged into another or if it’s the main one, the data keeps updated with the other company data)
We have an automation for this which looks into a deal close date and copies that to company property “Last closed won date” but after merger of 2 companies this automation won’t re-enroll these companies and we have to do it manually.
Does someone know a way that after merger the data doesn’t get changed or if it does the above mentioned automation re-enrols the deals of that company and updates the last closed won date to most recent date?
HubSpot does not have any options here which would allow you to specify which value to keep, unfortunately: Merge records
If you have a preference for what to keep, you would have to choose a main company record and then selectively edit properties with values from the to-be-deleted duplicate.
Thank for mentioning Insycle @karstenkoehler. I work there as a product marketer so I thought I would pop in here and give a little context around Insycle’s deduplication features, which allow for field-by-field data retention rules, which would allow you to solve this problem.
With Insycle, you can use any field in your HubSpot CRM as a duplicate matching field. You can also set rules for choosing the resulting post-merge master record (such as the most recently updated record, first created record, etc.)
For your use case, Insycle has field-by-field data retention settings. I’ve attached a screenshot below as an example.
For this, you’d instruct Insycle to keep the Lifecycle Stage of any merged record that was “Churn,” and potentially the “Last Close Won Date” from any record older than a year.
When merging companies, the tooltip on the Lifecycle stage field in the merge dialog says that the value “cannot be changed” and that the value from the primary record will be kept.
In practice, HubSpot’s documented behavior for company merges is that the lifecycle stage furthest down the funnel is kept, even if it comes from the secondary record. This is what actually happens in our portal and it conflicts directly with what the UI communicates.
This causes two problems:
Misleading UX (lifecycle stage): Users believe picking the “primary” company will protect its lifecycle stage, but it doesn’t.
Data integrity / reporting risk: Companies can be “promoted” to later lifecycle stages unintentionally when merging, and we can’t opt out or choose which lifecycle stage wins.
Conceptually, this also undermines the idea of a primary record in the merge flow. The primary selection is supposed to be the “more correct” or canonical version between two records; users reasonably expect that critical properties like Lifecycle stage will follow the primary record unless they explicitly override them. If a secondary record’s lifecycle stage can silently win anyway, it makes the primary/secondary distinction much less meaningful and harder to trust.
Additionally, the tooltip for associations in the merge dialog is also inaccurate. It indicates that only the associated records from the selected record will be kept, but in reality associations from both records are preserved in the merged record. This behavior (keeping associations from both) is actually what we want, but the tooltip text does not match what the system does.
Requested changes:
At minimum, fix the lifecycle stage tooltip in the merge dialog so it accurately reflects that “the furthest‑along stage will be kept” and note that this may be from the secondary record.
Fix the associations tooltip to clearly state that associations from both records will be retained in the merged record (with the usual primary-association rules, if applicable).
Ideally, give admins a setting or per-merge control to choose lifecycle stage behavior, e.g.:
Always keep primary company’s lifecycle stage, or
Always keep furthest‑along lifecycle stage (current behavior), or
Let user choose which lifecycle stage value to keep during the merge.
This would make merges safer and more predictable for teams that rely heavily on Lifecycle stage and associations for reporting and automation, and would align the meaning of “primary record” with user expectations.
