# Merging Duplicates **URL:** \ **Category:** HubSpot Ideas\ **Tags:** object\ **Created:** [July 31, 2019, 6:25pm UTC](https://community.hubspot.com/t/merging-duplicates/15556 "2019-07-31T18:25:57Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![sluskstout](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/sluskstout/32/20432_2.png) [@sluskstout](https://community.hubspot.com/u/sluskstout)\ **Post date:** [July 31, 2019, 6:25pm UTC](https://community.hubspot.com/t/merging-duplicates/15556/1 "2019-07-31T18:25:57Z")
The current merge process causes a lot of unnecessary double checking after the merge to ensure wanted data isn’t lost because of the merge rule sets in place - i.e. Keeping the most up to date field is not always the best or relevant information to keep. We came from a simpler CRM and we were able to cherry pick the fields we wanted to remain post merge and it was great feature. Now we have to go through and check each filed history to make sure we didn’t override the good data. ![Capture.JPG](https://d2qpr2jzcazej7.cloudfront.net/original/3X/c/e/ce540854d9f0d41dadc00d42c72fd1c04aa8553c.jpeg) Merge Future Enhancement ---
**Author:** ![BobG](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/bobg/32/97852_2.png) [@BobG](https://community.hubspot.com/u/BobG)\ **Post date:** [August 1, 2019, 1:26pm UTC](https://community.hubspot.com/t/merging-duplicates/15556/2 "2019-08-01T13:26:10Z")
I agree with Stephanie. this would be a great improvement ---
**Author:** ![MEATBALL](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/meatball/32/68653_2.png) [@MEATBALL](https://community.hubspot.com/u/MEATBALL)\ **Post date:** [September 11, 2019, 1:42pm UTC](https://community.hubspot.com/t/merging-duplicates/15556/3 "2019-09-11T13:42:00Z")
This would be a great improvement! I work with Stephanie, and while our old CRM program was antiquated, it did allow us to pick which data components we wanted to keep before the merge occurred. I think HubSpot should rethink the engineering behind its current dedupe process. ---
**Author:** ![MarcPozzuoli](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/marcpozzuoli/32/57097_2.png) [@MarcPozzuoli](https://community.hubspot.com/u/MarcPozzuoli)\ **Post date:** [December 11, 2020, 1:17pm UTC](https://community.hubspot.com/t/merging-duplicates/15556/4 "2020-12-11T13:17:28Z")
I agree with Stephanie that this is an issue. I would offer an alternate and easier to implement solution that might address the issue across all the available merges. Anytime you are merging data off of a record, place the deleted/overwritten data into the merge note or into a note on the record that details what happened and what information was lost from the structured data. This way we could fix any issues that arise at any time in the future. ---
**Author:** ![kcraft](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/kcraft/32/101089_2.png) [@kcraft](https://community.hubspot.com/u/kcraft)\ **Post date:** [February 9, 2021, 4:59pm UTC](https://community.hubspot.com/t/merging-duplicates/15556/5 "2021-02-09T16:59:08Z")
At least it would be good to not overwrite fields that contain data with fields that are blank. We see fields like address get overwritten with blank values often because the newer record doesn’t contain that more detailed data. ---
**Author:** ![FTally-Foos](https://avatars.discourse-cdn.com/v4/letter/f/b77776/32.png) [@FTally-Foos](https://community.hubspot.com/u/FTally-Foos)\ **Post date:** [December 6, 2022, 7:01pm UTC](https://community.hubspot.com/t/merging-duplicates/15556/6 "2022-12-06T19:01:35Z")
This would really help us as well. ---
**Author:** ![CMurphyUSD](https://avatars.discourse-cdn.com/v4/letter/c/5f8ce5/32.png) [@CMurphyUSD](https://community.hubspot.com/u/CMurphyUSD)\ **Post date:** [February 7, 2023, 10:50pm UTC](https://community.hubspot.com/t/merging-duplicates/15556/7 "2023-02-07T22:50:32Z")
This is a critical issue. Hubspot’s assumption that the most recent value is the most accurate overrides critical data having to do with a record’s origin. Rarely is the most recent data the value we’d want to keep ---
**Author:** ![MMurra](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@MMurra](https://community.hubspot.com/u/MMurra)\ **Post date:** [February 7, 2023, 11:15pm UTC](https://community.hubspot.com/t/merging-duplicates/15556/8 "2023-02-07T23:15:13Z")
We have found that after merging the records there is a need to go back and redo the information that was chosen by Hubspot so it is more relevant to our needs. It takes double the time that it should take. ---
**Author:** ![DHeywood](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/dheywood/32/92090_2.png) [@DHeywood](https://community.hubspot.com/u/DHeywood)\ **Post date:** [May 15, 2023, 9:58am UTC](https://community.hubspot.com/t/merging-duplicates/15556/9 "2023-05-15T09:58:36Z")
to add to this, the current set up of overwriting with the most recent value is really problematic when dealing with multiple checkbox fields. WE use these for event registrations and would expect to be able to merge both value sets (or choose to overwrite)