Normal 0
Our marketing department has for years allowed a path for new users to create a login without having to enter their mailing address or telephone number. The feeling is that some customers would like to be identified only by their email address, and that if they were forced to enter address and telephone they would abandon, or enter bogus information, which is worse than nothing at all.
In such situations the minimum information collected is login name, password, email address, first name and last name. Records thus created have the default mailing address of 252 Huntington Ave Boston MA 02115, our offices. There are now more than 15,000 such records. Every morning the merge constituents program suggests dozens (if not hundreds) of possible merges, the majority being newly created constituents with similar names and the matching default address. Unless we do a tedious examination of email addresses (once or twice a year only) we can’t confirm these records are duplicates and so we leave them be.
The problem I would like to solve is to prevent the merge constituents program from even bothering to look at records where the address is 252 Huntington Ave. Is there a way to add a mask which will cause these records to be completely ignored? Then we could speed through scheduling merges for the REAL duplicate constituents, always a handful every day.
If it is useful to know, our criteria for duplicate matching from T_DEFAULTS is fname=1,lname=20,postal_code=5,street1=3, which is good for most records with real addresses.
Hi Jon
It's easy enough to add a set of filters to the LP_IDENTIFY_DUPLICATES stored proc that will exclude uninteresting dupes from the list of potential merges, but it does require coding.
We maintain a local system table (LTR_GENERIC_STREET_ENTRY) ) which lists various dummy addresses that are or have been used by different consortium members, and then exclude any addresses from the address-matching process if they match any of those values.
The code that does that in LP_IDENTIFY_DUPLICATES is just this addition to the Where clause in the main criterion select statement :
and b.street1 not in (select description from [dbo].[LTR_GENERIC_STREET_ENTRY])
So the short story is that it's straightforward if you have access to basic SQL skills, but hard if you don't.
Ken