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
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.