When merging databases from different centers we've found duplicate/triplicate records. Obviously we need to merge records.
Does anyone have an opinion regarding which record takes priority? For example, do records with ticketing or donor information take priority over records with more limited information? If you can share your thoughts regarding prioritization orders (or anything we need to look out for), we'd be grateful.
Thank you. I will also post on the Marketing Forum.
Elizabeth Weisser / eweisser@92y.org / 212-415-5596
Unknown said: Does anyone have an opinion regarding which record takes priority? For example, do records with ticketing or donor information take priority over records with more limited information?
Does anyone have an opinion regarding which record takes priority? For example, do records with ticketing or donor information take priority over records with more limited information?
Since all of that data will be preserved in the merged record, we usually merge into the oldest record to hopefully reflect the length of the patron's history with us. We used to be on a system that wasn't easily able to find records based on the "delete" id if the patron supplied that, so we had to be more circumspect, but with Tess that isn't really a problem.
I think its safe to say that MOST data will be preserved but some is not transferred to the "keep" account in a merge. For example, N1 and N2 and Mail/Phone/Emarket Restrictions in the General tab are not transferred from the "delete" account to the "keep" account.
I recommend the document on this subject:
http://www.tessituranetwork.com/network/Learning/Documentation/General/Managing%20Duplicate%20Constituent%20Records.aspx
Unknown said: I think its safe to say that MOST data will be preserved but some is not transferred to the "keep" account in a merge.
I think its safe to say that MOST data will be preserved but some is not transferred to the "keep" account in a merge.
Correct. I meant to comment above re:our practice for choosing the "keep" record, and not to suggest that 100% of the data from a "delete" record is retained in the "keep". In addition to the fields you list, differences in the default salutation can be lost in this process. It doesn't hurt to check Association names, either.
Also bear in mind that an Attribute will not be transferred from the DELETE_ID if the KEEP_ID already has that attribute. For this reason we always merged into the newest record with the reasoning that the latest record PROBABLY has the most up-to-date information. For us here in Aus, this is particularly true when performing searches based on email address or mobile (cell) number due to the propensity of the (presumably younger) audience that tends to move physical address due to their being in the rental real estate market.
It does help that we're weaning people off being wedded to a particular CUSTOMER_NO.
Martin
Oh - and the "Original Source" that gets kept is that of the DELETE_ID and not the KEEP_ID (annoyingly) although someone may have amended the merge routine to correct this.....