Does anyone else have issues with staff and students creating multiple constituent records - one for their staff or student emails and then another for their personal email address?
We have found this to be a small issue on the front line as staff/students dont always recollect the email that they booked with so might struggle to locate their own bookings.
But more of a nuisance is that our merge utility pulls them up as duplicates because their name matches on both accounts... we then find that we cant really merge them because they are in theory two separate accounts so they all sit in the "select constituent ID to be kept:" list in the merge tool? It becomes hard then to see when other potential duplicates are added to that list by the utility. I know there is a way that we can mark the accounts so that they dont get pulled into that list but that doesnt really solve our problem because we still want the system to identify in future if a real duplicate has been created on one of the two accounts.
Does anyone have any clever criteria for the dupe function that can filter out these from being pulled in the merge utility?
Thanks, Lianna
Lianna Macari,
The kinds of multiple records per constituents you are describing are in my experience fairly common. I’ve been working on a case study of this issue with 5-10% of records being these kinds of multiple records for the same customers even in a fairly clean database. I’ve also noted that It often turns out for operational reasons like you are describing that merging such accounts can cause adverse customer experiences. And if you don’t merge your aggregate custom reporting will have fairly large error bars.
Regarding what to do about this I believe that some organizations use custom reports rather than the merge screen to find duplicates that have filters that look at different time frames to reduce the number of records that need to be considered. (This is sometimes referred to as “blocking” in the record linkage literature.)
Katie Lachance-Duffy Is in my mind one of the gurus of constituent merge purge in our community she might be able to share some of her sophisticated approaches to these questions. I belive that there are also some past TLCC presentations on this topic.
I'm curious why you feel that you can't merge the two accounts so they have both emails on their account.
We have a feed that loads all our school accounts students and employees and sets their constituency on their constituent record. If a person has setup their account with a personal account, we merge the two so that both the personal email and the school email is on their account and they can use either one and should still get the benefits of the constituency. Until that person leaves the school and then their constituency would change their school email account would become inactive and but they could still use their personal email as an external patron.
Thanks for your reply Lori. I didnt realise that having two emails on an account meant that you could log in with both addresses. Are you saying that the customer can log into their account with either email and it not cause an issue? how will they know which password to use then on logging in post merge? Sorry if this sounds obvious but it wasnt something that I had considered as an obvious solution!
Merging the accounts doesn't change the password for each email that I'm aware of. I believe it would be whatever password was setup for each email address, or they could reset it if they needed to. Logan Heinsch (Past Member) might be able to answer that a little better since he works in our Box Office.
To clear things up a little: there are eaddresses and there are logins, and they are two different things. "EAddresses" can technically be anything "E", a website url, a twitter handle, or an email address. Logins can also hypothetically be of various types -- or a while we had a login type for the Tessitura Facebook integration -- but are generally "web logins".
A login does require an associated eaddress, but the unique name of the login can technically be anything. It is a TNEW standard (and a standard for many custom websites) that the login be identical to the email address, for lots of good reasons, but the requirement is not built into Tessitura. It's important to remember this in case some error should cause them to fall out of sync. For instance, if a user in the client creates a web login for a customer, there's no tool or checking to make sure that the login is identical to the email.
In a merge, all eaddresses and logins are kept, by default. Logins must be unique, but you can have multiple logins of the same type as long as the login handle is different. Every one of them will connect you to the same account.
There is a subtlety when it comes to households, at least for TNEW. Logins can exist on the household or on individual records, or both, and of course either might have multiple logins. It is a TNEW requirement (and generally recommended) that all transaction occur at the household level, so even if you log in with an individual account, your purchases, card tokens on file, etc. will all live with the household. However, some things do remain at the individual level. One of those is Interests: if your login is connected to an individual account, then if you update your Interests then they will be set for the individual account, not the household.
Also, Constituencies "flow" from households to individuals, but not vice-versa, so if you log in with a login on the household record, Constituencies on any of the individual records will not be computed for ranking or pricing rules.
Gawain Lavers thanks for your input. Our students and staff email addresses are both @kent.ac.uk so presumably from what you have said, this could cause an issue with the same handle? whereas if they were different it would be ok? have I understood correctly?
I'm not sure I understand. Logins must be unique. EAddresses need not be. If you use TNEW it will expect Login to be identical to the Eaddress, so if two accounts both have john.smith@kent.ac.uk for Eaddress then they both can't have it for their Login, Tessitura simply won't allow it. If the two accounts each have john.smith@kent.ac.uk as an Eaddress (but not Login), then if merged then either both Eaddresses are kept, or perhaps it's smart enough to know that you only need one (since they're identical). Don't remember. It's definitely possible for a customer to have multiple Eaddresses that are the exact same email address on their account.
If one account has john.smith@kent.ac.uk for both Eaddress and Login, and the other has jsmith@kent.ac.uk for both Email and Login, and the accounts are merged, both Eaddress/Login pairs will be on the kept account, and either will allow John Smith to log in to his account. They will have different passwords.