• Replies 2 replies
  • Subscribers 415 subscribers
  • Views 105 views
  • Users 0 members are here
Related

Constituent Login Creation and Maintenance

Nicholas Hudson-Ellis (Past Staff Member)
$organization

Hello all,

I'm hoping to get a sense of how others manage the Logins of their constituents.

Do you always create a login with the email address when you create a new account?

Do you always update the login when a customer updates their email address?

I have been thinking about this because we have recently had some customer confusion when they try to generate a new password over the web, but fail because they never had a login created. 

I would love to know about any magic bullet that creates the login based on the email, and updates the login when the email is updated :)

Best,

Nicholas Hudson-Ellis

Parents
  • $organization
    Hi Nicholas!

    We did use a version of this script in the spring of 2012 to mass apply logins for our rollover subscriptions. It worked to a point, with some caveats:

    - We used this in version 10, but I'm not sure if you can do the same in v11, as it uses non-email addresses for login names (I think I read somewhere in our migration that non-emails are not recommended in v11).

    (I just found the following in the v11.0.4 help docs: NOTE: The email requirement for logins does not prevent the creation of temporary logins for constituents without an email address on file. When a constituent does not have an actual email address the email address for the login should be set to ID 0 to satisfy the email address requirement.)

    - I didn't realize until later, but this particular script applied a login/password if you had none (which is what we wanted) - but if you already had an email address, it would use that email as the login, and then just supply a temporary password. This seemed to create more problems than it solved, because it would tell people they already had an account, when in reality, we created it behind the scenes without their knowledge (not all these patrons were notified of a login creation).

    - We also use ONE login for all three organizations that we sell tickets for, which could in turn lead to some confusion (although we spell it out on the login page as best we can).

    - There may have been other issues - if I think of them, I'll pass them along (this is off the top of my head on a Monday morning!!) For what it's worth, we also use TNEW, if that makes a difference in your situation.

    All this being said, we are definitely looking to use something like this in the future, but completely rewritten in some fashion. (We first have to get through our very inconsistent database full of bad emails and insane amounts of merges before we implement anything more widespread than the very specific rollover orders again.)


    Beth
     

     

    UMS_Logo1 

     

    BETH GILLILAND

    Tessitura System Administrator 
    bethgill@umich.edu
    734-615-9579 //  734-276-4816 cell
    www.ums.org  //  www.umslobby.org

     

Reply
  • $organization
    Hi Nicholas!

    We did use a version of this script in the spring of 2012 to mass apply logins for our rollover subscriptions. It worked to a point, with some caveats:

    - We used this in version 10, but I'm not sure if you can do the same in v11, as it uses non-email addresses for login names (I think I read somewhere in our migration that non-emails are not recommended in v11).

    (I just found the following in the v11.0.4 help docs: NOTE: The email requirement for logins does not prevent the creation of temporary logins for constituents without an email address on file. When a constituent does not have an actual email address the email address for the login should be set to ID 0 to satisfy the email address requirement.)

    - I didn't realize until later, but this particular script applied a login/password if you had none (which is what we wanted) - but if you already had an email address, it would use that email as the login, and then just supply a temporary password. This seemed to create more problems than it solved, because it would tell people they already had an account, when in reality, we created it behind the scenes without their knowledge (not all these patrons were notified of a login creation).

    - We also use ONE login for all three organizations that we sell tickets for, which could in turn lead to some confusion (although we spell it out on the login page as best we can).

    - There may have been other issues - if I think of them, I'll pass them along (this is off the top of my head on a Monday morning!!) For what it's worth, we also use TNEW, if that makes a difference in your situation.

    All this being said, we are definitely looking to use something like this in the future, but completely rewritten in some fashion. (We first have to get through our very inconsistent database full of bad emails and insane amounts of merges before we implement anything more widespread than the very specific rollover orders again.)


    Beth
     

     

    UMS_Logo1 

     

    BETH GILLILAND

    Tessitura System Administrator 
    bethgill@umich.edu
    734-615-9579 //  734-276-4816 cell
    www.ums.org  //  www.umslobby.org

     

Children
No Data