Large enterprise application - clients wish to use duplicate e-mails addresses?

Question

I'd like to know people's opinions, reactions to clients and technical work arounds (if applicable), to the issue of an enterprise application where a client wishes to use duplicate e-mail addresses?

To clarify, when I say duplicate e-mail addresses I mean within the same client system, having multiple users that have the same e-mail address. So not just using generic e-mail addresses but using the e-mail address of another user.

e.g.

Bob Jenkins: [email protected]

James Jeffery: [email protected]

Context

To give this some further context, in the e-learning sector it is common that although all staff in an organisation must complete e-learning - they may not have their own e-mail address so they choose to use their managers e-mail address.

Albeit against good practice in public sites... it's a requirement we've over and over again where an organisation is split between office based staff and perhaps e.g. staff in a warehouse.

Where problem lies

Mr Steak, good point, the problem lies in password resets and perhaps in situations where semi-personal information could be sent (not confidential enough to worry about the insecurities of email). Perhaps reminders for specific system actions, which would be confusing for the unintended party to see (if perhaps misreading the e-mail's intended recipient)

Possible solutions

• System knowing the difference between a "for the attention of" and direct to the person e-mails, including this in the body text.
• Using alternative communication such as SMS
• Simply not having e-mails sent to people who are not the intended recipient.
• Providing an e-mail service ourselfs (not really viable for a corporate IT dept)

Thoughts?

Answer 1

I'd suggest this is a bit of a non-issue for the scenario you describe.

My answer will stay within the realm of your scenario of an e-learning site, supervisors who have access to corp email, and workers who neither access nor need corp email.

If the stickler is password resets, provide additional mechanisms to reset their password other than email. Challenge / response systems are a convenient way to do this. Allow the end users to pick from a large set of questions to where they would be the only ones (in that environment) who should know the answer.

If training reminders are an issue, then gear the reminders towards the supervisor. Provide the reminders in the form of a report. "These users are X days from being delinquent on training" or "These users are Y days from needing a refresher" or similar. Part of the supervisor's duties are to make sure their employees stay current on training. Make the reminder a report that simplifies their responsibilities.

Adding in the ability to receive text messages would be a bonus. Keep that as an opt-in only since most workers will not be issued corporate phones. Otherwise they will resent being forced to use personal property for company work.

Providing alternate email systems ignores the fact that the workers don't check email at work. If they did, they would have corp email accounts. The challenge to solve here isn't providing them with corp email accounts. The challenge is to provide some measure of authentication where email is not available for password changes and reminders.

Answer 2

Not having a unique e-mail address for each registrant effectively eliminates e-mail as a an option of communication and as an option of identification. However, this is not the end of the world:

If you cannot use e-mail for communication or identification, don't ask for it at all

That's right, just skip e-mail altogether: as far as your application is concerned, it is perfectly useless.

Lack of an e-mail requires you to make two decisions:

1. How do you identify a registrant, and
2. How do you communicate with a registrant

The first question requires a registrant to provide something unique that is also external to your application. You may not ask for government-issued identification number, but an employee identification number issued by the corporation should be perfectly valid. This number can be used for password resets and other situations when unique identification is essential. Using a phone number should be another option, assuming that the corporation has the record of the phone number of each employee. Sending an SMS with a unique registration number to a phone number provided by the employee is yet another way of establishing the unique identity. If everything else fails, you can print a letter with a unique number for each employee, and send it to their home address or distribute them to employees through their supervisors.

Communicating back to the employee becomes slightly more problematic, because the "push" model of the e-mail no longer works. You can take the SMS route again, but you can also switch to the "pull" model, when you ask the employee to log back in after a certain period of time to check for communications intended for her or him. This is similar to the strategy that some tax preparation programs adopted, when users must check after 24 hours to see if their returns have been accepted.

Answer 3

Email adresses should really be unique within a database. Creating an email adress is so trivial these days that every one should have its own. You stated all the reasons yourself to require a unique email adress per person :

Confidentiality

Just look at every possible website that requires registration. If you try to register with an adress that is already used, they don't let you create your account. Just do the same thing and everything will be fine.

Sure it also depends on the kind of information that your application will send by email. If you don't send any sensitive information, confidentiality will not be an issue. However, if you use it for logging in, then you cannot have multiple people with the same email.

But even if you don't send anything sensitive, I strongly advise you to require unique email adress. You don't know how your application is going to evolve and you might want to send such information in the future. Just take that precaution right at the start and it might save you lots of headaches later.

Answer 4

My opinion, In this situation we can have two Emails (Db Columns - PersonalEmail & AdminEmail):

1. Personal Email- Queries will be sent to the respected user.
2. Admin/Support Email (For who doesn't have personal company email) - Queries will be sent to the company Systems Administrator/Support team who is responsible for the user accounts and who can also solve the user related queries within the organisation.

Cheers!

Answer 5

If you have some people who are not allowed to have e-mail addresses, let them all share common ones. For instance:

[email protected]

Or similar general addresses.

It still seems weird that you cant create e-mail addresses for people though, but I can see how some mobile people might not be able to log in and out of accounts constantly.

Answer 6

Assuming that we're talking about internal applications where having users register for a free email account is inappropriate, if not every user of your application will have a corporate email address, I would simply make the email address optional. If a user has a corporate email address, they can enter that address. If the user doesn't have a corporate email address, they won't.

You can deal with password resets in a number of different ways without requiring an email address. You can allow a user's manager or an administrator (i.e. helpdesk) to reset a user's password. The user would, presumably, need to call their manager or the helpdesk to get their password reset. You can let the user reset their own password online without email by answering some questions. This can be the standard "security questions" that you'll find at various sites, it can be things like an employee number that is likely to be assigned whether or not the user gets an email address, it can be information about the account's activity. Which options you use will, of course, depend on the sensitivity of the information stored in the system-- in the context of required e-learning, I'm guessing that the risk of allowing someone to compromise my account so that they can sit through a required corporate ethics training class is relatively low so the bar doesn't need to be set particularly high.

Reminders and other emails can be sent to the user if they have an email address and/or to their supervisor depending on the specific nature of the email. That lets you suppress unnecessary emails with personal information if the user doesn't have an email address but lets you alert the supervisor if an employee is overdue for a particular training class.

Answer 7

It sounds like you are conflating user identity with email address. If that's the case, then insist on it. Users who don't have a personal email address can easily get one. Or you can easily provide one as part of your service.

In view of the inherent unreliability and complexity of getting email to work "for everyone", an alternative would be to design your interactions to be self contained and not require email for routine interactions, or ideally not needed at all.