With regards to web logins in version 11...
We understand that one method to deal with newly created individual logins (from the migration process) is to use different login types. For example, a couple who used the same login and password in version 10 now has two individual logins in version 11 - identical other than the login type, which prevents a data conflict.
However, we are having trouble understanding how the web site (or the API) will determine which of the two individuals is logging in. Does this require some magic on the web developer side, or is there a process in the API that helps determine which individual is the one logging in?
We are particularly interested in this process in the way that it affects updating interests online, and also how the ShiftContext method comes into play.
Thanks in advance for any advice or help finding documentation on this.
Did your migration really create *duplicate* web logins, i.e. truly identical data, including username and password, with the only difference being the login type? Sounds like a migration bug, if yes.
I can't see how this would work, as it would indeed be difficult to determine which login is being used.
Hi Josh,
I've reviewed the Tessitura v11 documentation and as I understand it, the recommendation is to attach logins to individual records if they have a N1/N2 flag. But, if the login is flagged 'both' it should remain on the household (and therefore not create duplicate logins).
The new ShiftContext method will allow developers to use the existing API to work with the individual members of a household as individuals (i.e. update individual interests). However, if significant code work is being undertaken to do this, we recommend using the REST API for implementation of this functionality. You can find more information on ShiftContext in the v11 SOAP API documentation.
I hope this helps,Karyn
Hi Karyn,
Thanks for the quick response! I should clarify that we haven't done our migration yet, but this is perfect information.
It makes sense that we should leave the login information (if not N1 or N2 specific) on the household. Have you heard from early adopting organizations on v11 about successes or failures with using ShiftContext to update individual interests? I assume that all organizations will want to do that since managing individual preferences is a lot of the attraction behind the new functionality in v11. I also assume that most orgs, like us, do not have many N1 and N2 specific logins in their current data.
Thanks again,
Josh
Hi Chris,
Thanks for responding. We actually haven't done our migration yet, but I can tell from both your response and from Karyn's that my assumption that we would create logins for the individual account, even when the logins were not N1/N2 specific, was not right.
How is Guthrie handling the issue of allowing individuals to update their interests separately when the login is a household login not specific to the individual?
One follow up question...
Below the note from the migration worksheet document that led our organization to think that we did need to attach logins to the individuals and figure out a way to prevent data conflicts. I think that I misunderstood and thought that this note was talking about all logins, not just those with the N1/N2 flag on them.
Default Field Name: LEAVE_CONTRIB_ON_GROUP
Response = Remain on Household à Default Value = Yes
Response = Attach to Individuals à Default Value = No
2) Should web logins be attached to newly-created individual records or remain on the household?
Attach to Individuals _______ Remain on Household ________
Additional Info: The existing SOAP Web API will continue to build transactions on the household even if the login is attached to the individual record as long as no changes are made to your existing website and the recommended default settings for transactions are followed (required for website backward compatibility). When logging in to the website as an individual affiliated with a household the context will automatically change to the household. It is strongly recommended that the login attach to the individuals.
So... am I correct that all nonspecific logins stay on the household, and the only ones that are moved to the individuals accounts are those with a N1/N2 flag?
You are correct, if you accept the recommended Attach to Individuals (default value of No), then the Name1/Name2 flag will be followed as it is for the rest of the data; Name 1 moving to the A1 record, Name 2 moving to the A2 record, and Both remaining on the household.
Best,
Anna
Thanks Anna, all. I think we understand now.
I appreciate the help!