Hi all -
We just moved over into V15 - and we're working through some new features. We received this error for the first time "Constituents Can Only Be Scheduled Once for a Single Merge." We've never encountered this before in other versions. We've done our due diligence and read about merging in V15 - but can't figure out how to merge Account Numbers 2 and 3 into 1 during the same merge procedure. Any ideas where we are going wrong?
Also, is anyone using any jobs for merges overnight that they really like? We've been doing it manually for awhile now. I've worked for other organizations that had jobs that ran overnight that looked for potential duplicates, and I'm looking into possibilities of implementing this here.
Thank you!
Hi all and thanks for the feedback on this topic. I totally recognize the extra effort that this change has caused, and say that we are working towards a better solution. We made the change primarily, as Kevin said, because there were cases where performing multiple merges at the same time caused potential loss of data or data ambiguities. This was a particular problem when performing multiple merges on accounts that were members of households.
As to the general topic of duplicate accounts created in web or mobile transactions, we would love to have feedback on strategies to deal with that problem, given the constraints that we have around privacy and not being able to reveal personal information. What can we do up front, or in a more automated back end way to lessen the number of duplicate accounts?
--chuck
Chuck Reif said: This was a particular problem when performing multiple merges on accounts that were members of households.
So why not make it so that Individuals associated with Households can only be merged 1x/day and let unassociated Individuals keep on keeping on?
Chuck Reif said:there were cases where performing multiple merges at the same time caused potential loss of data or data ambiguities.
Given that each merge happens individually, i.e. from the notes of AP_MERGE_CUSTOMER2, "This procedure prepares the identified duplicates and merges them one by one in a cursor, calling AP_MERGE_CUSTOMER for each", what difference does it make if more than one Delete record get merged into the same Keep?
If the first merge (A < B) happens successfully, I'm puzzled how A < C cause data loss or ambiguities? Were these cases of A < B < C? Or...?
Never run into anything like this over countless "A < B, A < C" merges on the same day. Are we disabling valuable functionality for the sake of a few corner cases?
Hey Chuck,
I don't know how other sites do it, but I've tried to create accounts on other sites and have had messaging that tells me an account already exists with that email address as a login and to submit to have a password reset done. I don't have any idea the coding those sites use to do that, but I know it exists. Maybe create logic in Tessitura to automatically create a web user account for any newly added email (including for phone and window purchases). If that was an automated process, then guests wouldn't then go online and try to log in and see they have no account...and then create another one. Since the logic already exists that only one email address can be associated to one web login, I could see this mitigating a huge portion of duplicate accounts.
As to the merge process....I concur with Chris Jensen. I have seen orphaned accounts happen when merging households together.....but that happens so infrequently, I don't see it as a huge problem. It's also easy to correct that and remove the orphaned account from the merge window. Perhaps also create a utility that could be used to delete those orphan accounts instead of having to do it via SSMS? I know there is also issue with analytics and merged accounts but that is always going to be an issue. Perhaps logic needs to be written for analytics to understand how merged accounts work in Tessitura?
Beyond all that...clear and concise documentation about version upgrades has to be provided to us and all help documents need to be updated BEFORE a general release happens of a major version upgrade. I'm not so worried about service pack upgrades (but would hope that eventually any changes from service packs is added to general documentation for each version). Communication is key and if it's not accurate or missing information, then we aren't prepared and get blindsided when we experience an issue we didn't know would happen. This is why I will always advocate that Tessitura take more time on general releases than trying to push something new out every year. In my 10 years using Tessitura, I feel like there's been too much of a rush to push all this new stuff out and because of that, other things are breaking that used to work just fine. Since V11 it's just been non-stop with major release after major release. We barely have enough time to learn the current version before a new one is out with even more significant changes to the database...that we now have to learn.
Christopher Cuhel said:I have seen orphaned accounts happen when merging households together.....
Does this happen when the A1/A2 affils from one hhold get merged into the A1/A2 of another, without merging the hhold record itself? If yes, it seems to me that a built-in check forbidding *that* would be fine. If hhold + affils are being merged into an existing hhold + affils, I'm still wondering where the orphans come from.
To be honest, I've never really paid attention to the rationale of what happens in that scenario....because it happens so infrequently. When it does, I just go into SQL, use the code I've saved, and remove it from the table.