In a consortium environment, in what ways have you reduced the duplicate accounts created by patrons as web site users?
David,
This is something I have spent a lot of time and energy on in a couple different consortia. My biggest step was to convince folks that there are some accounts that can be merged without human intervention. So at night a process runs which identifies new accounts created through the web from the previous day, makes a rigorous check against existing accounts (exact matches on first and last name, email and sometimes mailing address) and then merges the accounts without any users needing to take action.
Another step we take in Dallas is to create web logins for any account with an email address on it using a nightly SQL job. That way, if a patron tries to create a web account using and email they already have on file with the consortium, they are informed that an account already exists and prompted to use the "forgot password" functionality to access the account.
Dealing with web created duplicates is a full time job, but with some planning and strict data standards it can be made into a manageable process.
Hi Levi and David,
We struggle with similar issues with our consortium, but haven't yet implemented any auto-merging at this point. So we have a lot of duplicates in our database, as I'm sure you can imagine. I'd be interested in seeing the procedures you use to do this if you are willing and have the time to share them. In particular, I'd like to see what criteria you use that is deemed safe to auto-merge.
Thanks!David Frederick