• Replies 7 replies
  • Subscribers 251 subscribers
  • Views 48 views
  • Users 0 members are here
Related

Managing duplicate web logins in v11

Josh Hart
$organization

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.



[edited by: Josh Hart at 10:09 PM (GMT -6) on 20 Mar 2012]
Parents
  • $organization

    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

  • $organization in reply to Karyn Elliott

    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

Reply
  • $organization in reply to Karyn Elliott

    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

Children
No Data