Neptune – web based lead management / tracking tool – email address conflict

Last week I spoke about the upgrade to Neptune in that Neptune now accommodates multiple users per account. Originally a Neptune user-account was the whole account. With the advent of the modifications last week a user-account now has a one to many relationship with an account thus allowing for multiple user-accounts under a single account.

Visit Neptune here …

www.neptuneleadtracker.com

I thought this was suitable for purpose until I started thinking into some of the scenarios that could crop up when Neptune finally goes live. If Neptune was left with this solution then the user-account could not be shared across different accounts. Lets say a person from Account A wants to add Jon Doe to his account and a person from Account B also wants to add Jon Doe to his account. This scenario would not be possible without Jon Doe having 2 different accounts with different emails addresses meaning Jon Doe would have to create another email address to have an account with Account B …

Account A
User-account A – Jon Doe

Account B
User-account B – Jon Doe

User-account A and user-account B both would have different email addresses. User-account A and user-account B are represented as 2 distinct user-accounts.

The above system could be improved upon so I set upon improving it. I came up with 2 solutions …

Solution 1

Keep the one to many data structure between the account and users and have it so “email addresses” do not have to be unique in the users table. The email addresses would then only have to be unique per account they are related to. I could then give each account a special login URL which is unique to the account in which the user-accounts can login with. This would result as follows …

Account A
User-account A – Jon Doe

Account B
User-account B – Jon Doe

Although it looks the same as before, user-account A can have the same email address as user-account B, in the old model this was not so and user-account A had to have a different email address to user-account B. User-account A and user-account B are still represented as distinct user-accounts though. The system would know which account the user was attempting to access via the special login URL given to each account and the system would only have to check the uniqueness of the email addresses for each given account.

Solution 2

Get rid of the one to many data structure and replace with a many to many data structure. This solution is the most taxing in terms of implementation as the code would have to be altered in the system to accommodate the many to many relationship which also means swapping a few other database columns round and getting rid of some as they would be no longer needed.

Luckily due to the way the system was abstracted in the code, it turned out that most of the changes could be accomplished by altering a few class methods. Essentially just changing the way those methods returned the data they where fetching from the database.

Using this solution the result now looks like the following …

Account A
User-account A – Jon Doe

Account B
User-account A – Jon Doe

In this solution both accounts share the same user-account. The user-account obviously uses the same email address as it is the same user-account across both accounts. If a fictitious Account C wants to add Jon Doe to their account the system would first check if the email address for Jon Doe exists, if it does then the system will link the Jon Doe user-account to Account C, if not, then the system will create a new user-account for Jon Doe and then link the newly created user-account to Account C.

When a user logs into the system using this solution and the user belongs to more than 1 account the system will present a list of accounts that the user-account belongs to in a selection list. The user can then choose which account to fully log into. If the user-account is only in 1 account then the user is taken straight to the account.

In the end Solution 2 was chosen in favor over Solution 1.