How should I structure tiered user accounts for a portal?

[DeX]

Currently I have a portal which requires a salesman login in order to create or view customer quotes. When the salesman emails a quote to a customer, it simply emails out a link with a token attached to it and when the customer clicks the link to view their quote, the system will provide it if the correct token is supplied. This allows customers whom are not logged in to view a quote behind the login.

 

What I would like to do is to give customers the ability to have their own login created automatically when a new quote is generated for them and they can just log in under their account to view all of their quotes they have for them. I'm wondering which way I should do this, since the users and customers are in 2 separate tables in the database.

 

1. When creating a quote which creates a customer, also create them a record in the users database so they can log into the system (with restricted access).

2. Instead of creating a record in the customers table, just create them a record in the users table and start using that to fetch customer information from instead.

3. Also allow login access for any record in the customers table and add a password field to that table.

 

Which is best?

[requinix]

What I would like to do is to give customers the ability to have their own login created automatically when a new quote is generated for them and they can just log in under their account to view all of their quotes they have for them.

I suggest reconsidering that. Creating accounts automatically for people is weird, and could be jarring to them. "When did I sign up here? Why do I have an account?"

There's also a more practical matter: how do you get the user to log in? You'd have to send them account information through email. That's not secure, and really you shouldn't be doing that for quotes either.

 

How about giving the user the choice? If they haven't signed up before,

a) They can use the token-based method to view a single invoice without having to sign up. Maybe they only need this one invoice and will never deal with you again? Or maybe they don't want to have to manage yet another account on yet another website. You should install a sort of pseudo-authentication mechanism with these anonymous views too, like prompting for something the customer knows but that you did not also send in the notification email.

b) They can sign up, and the system can automatically match up their customer information with invoice information. If they sign up then token-based methods should be disabled for the account; attempting to use a token link would route them through a login interstitial page.

 

When they sign up, don't do it with something that you sent over email. Especially not a password. Ask them to provide information you already know about the customer (that was not sent in an email) and once you've established their valid identity you can prompt them to create a password and complete registration.

 

 

Answers here vary with what your system is and how it works...

1. When creating a quote which creates a customer, also create them a record in the users database so they can log into the system (with restricted access).

I would keep users and customers separate because they are two different concepts: a customer is part of your sales system, while a user is an account provided to people in order to access the system. Obviously, a user could be associated with a customer (maybe more than one?).

 

2. Instead of creating a record in the customers table, just create them a record in the users table and start using that to fetch customer information from instead.

That increases the complexity of the system (having to decide whether something corresponds to a customer or to a user), and makes it harder to maintain integrity in the database (foreign keys must be between two tables, not between one table and a choice of two other tables).

 

3. Also allow login access for any record in the customers table and add a password field to that table.

If you don't want separate users and customers then this is basically what you would have to do.