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 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?
Thanks again,
Josh