Wrestling With Email Address Limitations

Dynamics CRM has been around for a while (about 13 years) and, as is the way with any software, there are a few design features from the old days which linger today. One of those is how email addresses are treated for Accounts, Contacts, and Leads.

How Emails Work in CRM

Basically, for an Account, Contact, or Lead you have three email addresses: emailaddress1, emailaddress2, and emailaddress3. All three are used for linking Activities to records but you can only email out using emailaddress1.

When the smartest developers in the room built Microsoft CRM 1.0, they decided that the product would email a record and not an email address, and the email address used by that record would always be emailaddress1. If you type in an arbitrary email address in the CRM form, it will error, as it expects a record.

Naturally, some customers want to go beyond these limits. So what are the options?

Storing More Than Three Emails

While you can add additional email fields to a Contact, Lead or Account record, they are not very useful. Dynamics CRM will not use them for tracking Activities and, as they are not emailaddress1, you cannot send out with them.

Another option is to store emails against child records. If you are planning to use these email addresses for Marketing Lists, the child record will need to be a Contact, Lead or Account (the only entities which can be added to a Marketing List).

Which entity you pick will depend on the constraints of the solution being built. If you are using Accounts to store organisations, it might be a bad idea to use Accounts to store emails for, say Contacts, if you are using Leads as part of your sales process this might cause confusion if you also use them to store emails. Similarly, recycling Contacts as a child against Contacts may also trip users up.

Whichever you choose, CRM will track against these child records but it will associate the Activity to the child entity and not the parent. If this is an issue, the Activity could be re-related to the parent via a workflow or plugin.

Generally, if you are going to go down the route of storing emails in child records, I recommend you restrict yourself to one email address per child record. If you use all three email address fields you set yourself up for the same problems with the child record that you were trying to address with the parent record.

Sending From Something Other Than Emailaddress1

There are two option for this. The first is to use a product like ClickDimensions. ClickDimensions allows email Campaigns to be sent out with any of the three emailaddress fields. So, for example, you could set emailaddress2 to be an ‘official’ email address that every registered Contact has. Then, for an email Campaign which must get through, you can tell ClickDimensions to use emailaddress2.

The second option is to throw code at the problem. While the Dynamics CRM API enforces the concept of emailing to records, not email addresses, I am assured that it is possible to intercept an email via a plugin and cc to whatever email address is desired. Therefore, again, emails could be cc’ed to emailaddress2 or emailaddress3 via code.

Conclusions

The limitations built into Dynamics CRM around email addresses can be annoying but they are not insurmountable. Also, as concepts such as ‘emailable entities’ are fleshed out, I hope these limitations will disappear. Until then, we have the above options to work around the constraints and minimise the pain.