How are you dealing with records in the merge window that aren't actually dups?

Does anyone have code or a process they are willing to share for identifying records that aren't the same and shouldn't show up in the merge window? We stay pretty on top of our merges and we are now at a point where 80% of our suggested merges are records that appear similar but aren't and shouldn't be merged. I would love to have a way to identify these records as not being the same so they stop showing up in the window making it harder to see the actually records that need merged. Any help would be appreciated.

Parents
  • Similar to NIck's approach, I also have customized the duplicate identification process to remove any groups that are either on the same household or have a relationship with each other.

    And likewise to Gawain, I have a custom table that I populate (via script) after going through the current list of potential duplicates that records all of those false positives along with the current date. I then have an option in the duplicate identification process to ignore these groups as well, unless either of the customer records has changed since that row's creation date. The idea behind this is that some groups aren't as much false positives as they are unsafe to assume that they're duplicates, and so until we have more information (i.e. additional activity on the record) we'll ignore them in the de-duping process.

Reply
  • Similar to NIck's approach, I also have customized the duplicate identification process to remove any groups that are either on the same household or have a relationship with each other.

    And likewise to Gawain, I have a custom table that I populate (via script) after going through the current list of potential duplicates that records all of those false positives along with the current date. I then have an option in the duplicate identification process to ignore these groups as well, unless either of the customer records has changed since that row's creation date. The idea behind this is that some groups aren't as much false positives as they are unsafe to assume that they're duplicates, and so until we have more information (i.e. additional activity on the record) we'll ignore them in the de-duping process.

Children
No Data