Duplicate Management

Hi all,

Would anyone be willing to share their duplicate management processes and procedures (who can merge which records, what criteria do you use for identifying dupes, how you determine keep / merge record, etc...)?  We're merging something like 15 databases into Tessitura when we launch and want to be sure we're ready to tackle the clean-up task at hand as well as try to keep things relatively clean into the future.  If you have any documentation you've written that you're willing to share I'd love to see that too.  

Thanks!

  • In general, I am the only person who merges accounts. People who want accounts merged either set up a CSI/reminder specifying what they want (preferred) or send me an e-mail.

     

    I don’t worry about every duplicate in the system. I run the AP_IDENTIFY_DUPLICATES procedure a couple of times a day using a parameter of 2 days to catch any duplicates for accounts that have had activity in the past couple of days, and I merge those. I merge accounts that have the same name and e-mail address, no matter what the address/phones have. I don’t necessarily merge people with the same name and address because they are often parent/child. Any accounts that I don’t know whether to merge, I put a CSI in BOTH detailing the customer numbers/names. This CSI puts an alert in the constituent header so that anyone talking to the patron can say, “By the way, Mr. Smith, I see that we have three accounts at your address with your last name.”

     

    When I merge accounts, I try to keep the oldest version of postal and e-mail addresses, which sometimes means updating a login with an older e-mail address and then deleting the newer duplicate. I will also update web orders so that they are connected to the correct version of the e-mail address. I haven’t automated this yet because I am paranoid about e-mail settings, but it could probably be done.

     

    I set up an emergency report that runs via the Tessitura client which two other people have access to in case an account needs to be merged in a hurry and I am not available to handle it, but it almost never gets used.

     

    When we import constituents (happens occasionally), I usually spend a few days merging, because I import them even if they are flagged as potential duplicates so that I can get any data they contain that I might not have had, but otherwise this process is not too onerous. We don’t have the volume of a large performing arts center, though.

     

    Merging is not rocket science, but the potential for making a mess is great, so when in doubt, I prefer not to merge two accounts. One CAN unmerge if one has access to MS SQL Management Studio, but it is not a lot of fun to do.

     

    We use the Void Merge attribute in a very few accounts that absolutely should not be merged—intentional duplicates.

     

    Lucie

     

    ______________________________
    Lucie Spieler
    IT Development and Training Manager
    FGO_logo_one_line_2color_web.jpg