Usernames and Emails

Hi,

I am working through building a web application in PHP that talks to the Tessitura SOAP API. One thing I've noticed is that in Tessitura a Constituent can have the same primary email address as any other Constituent. However, a Web Login email address must be unique across the system. This seems like a problem when creating Web Logins for pre-registered Constituents... It's not clear to me how to automatically tie a Web Login registration to an existing Constituent via the API...

Anyone able to clarify?

m

Parents
  • Former Member
    Former Member $organization

    Hi Micah,

    We just launched a new website and went through a big process of cleaning up and organizing logins. If I understand correctly, you want to be able to have someone register online, and if their email address already exists in the system, then link it to that constituent record?

    To the best of my knowledge this isn’t possible, as the email address in question may exist on > 1 account and therefore the API would be unable to tell which to link it to. If someone knows something different though, please jump in!

    What we did to get around this (mainly to stop duplicates from being created) was to create a local procedure that is run BEFORE the API tries to register a new account. This SProc simply searches for the email address in Tessitura and has 3 outcomes.

    1.       If the email address is attached to a login, it lets the regular Register API call handle it which results in them being unable to register. They are instead directed to the ‘forgot password’ instructions.

    2.       If the email address is not associated to a login, but it’s in the database, then the Register API call is never evoked and they are stopped from registering online. They are instead directed to contact customer service to retrieve and update their login details. This can sometimes involve the operator merging accounts.

    3.       If the email address is not found, then they can register.

    The other thing we did was to actually create logins for all our Members and Partners that had an email address, but no logins (using a SProc). We used their Constituent ID as their temporary password and sent them an email telling them how to log in.  That way, we could try and avoid option #2 as much as possible. At the end of the day, nothing helps more than having a beautiful clean database with no duplicates, but in reality that can be quite hard to achieve. 

    Hope that helps,

     

    Natasha 

Reply
  • Former Member
    Former Member $organization

    Hi Micah,

    We just launched a new website and went through a big process of cleaning up and organizing logins. If I understand correctly, you want to be able to have someone register online, and if their email address already exists in the system, then link it to that constituent record?

    To the best of my knowledge this isn’t possible, as the email address in question may exist on > 1 account and therefore the API would be unable to tell which to link it to. If someone knows something different though, please jump in!

    What we did to get around this (mainly to stop duplicates from being created) was to create a local procedure that is run BEFORE the API tries to register a new account. This SProc simply searches for the email address in Tessitura and has 3 outcomes.

    1.       If the email address is attached to a login, it lets the regular Register API call handle it which results in them being unable to register. They are instead directed to the ‘forgot password’ instructions.

    2.       If the email address is not associated to a login, but it’s in the database, then the Register API call is never evoked and they are stopped from registering online. They are instead directed to contact customer service to retrieve and update their login details. This can sometimes involve the operator merging accounts.

    3.       If the email address is not found, then they can register.

    The other thing we did was to actually create logins for all our Members and Partners that had an email address, but no logins (using a SProc). We used their Constituent ID as their temporary password and sent them an email telling them how to log in.  That way, we could try and avoid option #2 as much as possible. At the end of the day, nothing helps more than having a beautiful clean database with no duplicates, but in reality that can be quite hard to achieve. 

    Hope that helps,

     

    Natasha 

Children
No Data