In going through the Merge Duplicate process, there are some constituents that were auto identified as potential duplicates but we have determined to not be duplicates. Does anyone know a way of individually removing these constituents from the potential dups window at the top of the merge screen? I'm currently left with a bunch of constituents that were identified as potential dups but are not and have to sift through them all every time I go to schedule merges.
There is a parameter on the identify duplicates procedure that is intended to control when duplicates that were identified but not merged end up back on the list. The parameter is @changed_since_days. When set to NULL, a pair of potential duplicates that is not merged will not be added to the list of potential duplicates again unless one of the records has had activity since the last time the merge procedure ran. If you set it to a number, a pair of potential duplicates that is not merged will not be added to the list of potential duplicates again unless one of the records had activity in that many days.
Since this is looking at activity on an account, it's not foolproof, but it should keep most potential dupes that you don't merge off the list. I would check what the parameter is currently set for at your organization. Sometimes it gets set to several years, particularly when you first start running the procedure to find potential dupes, so that it grabs everyone. If your list of dupes is reviewed pretty regularly, you can set it to Null or a smaller time frame. Here's a link to the help topic that describes this parameter: www.tessituranetwork.com/.../Identify-Duplicates-Procedure.htm
I cannot speak for anyone else, but a number of our accounts that look enough like each other that they end up on the suggested duplicates list are businesses and patrons with whom we are regularly doing business. So they do regularly appear on our suggested duplicates list even when not merged since the accounts are continually having activity. For the record, we run ours with that value set to 9999 (and we have not been in existence for even half that long).
It is possible I am mis-explained my response to Kevin Sheehan's post. My understanding of the @changed_days_since is that, assuming it has the value of X, if the patron activity on the patron's account is within the last X days, it will get suggested again. If it has not had activity in the last X days, though, it will not. So yes, a large number (such as we use), would continually keep pulling all accounts regardless. Which makes sense. But, even if we turned that into a smaller number (which we do not want to do just yet as our database is still actively being cleaned and de-duped to the point where we want to keep finding everything), there are still a number of accounts that would appear on the list every month. Additionally, we do not want to keep that number TOO low because we often just cannot get to all of the suggested merges at one moment in time. So we need the list to remain at least somewhat fully regenerative.