Salesforce Contact multiple Emails - suggestions?

Question

Looking for ideas on how to manage multiple emails in Salesforce. Think of the scenario where you have a contact that has a primary email address (say the work email address), but you want to communicate with them using an alternate email address (say their private email address). What if you have clients that might have 4 email addresses? How would you manage that? What are the draw backs?

All suggestions will be welcome.

Thank you.

Answer 1

This is a very broad question, and every answer will be specific to the context of what you want to do when.

If you have an automated-emailing system setup, you could set up all sorts of fields to determine which email to use to send a Contact an email. For example, suppose you have two fields: Email and Personal_Email__c. You could add some checkboxes that determine which email to use depending on the use case. Let's have a checkbox called Always_Use_Personal_Email__c. Maybe Class_A always sends emails to Email, while Class_B sends an email to Personal_Email__c if Always_Use_Personal_Email__c = true. It really depends on how you want to use it.

What attracted me to this question was your question asking 'how to manage many email addresses without knowing how many to store?'. To solve the question of how to store an arbitrary list of email addresses related to a contact, my initial reaction was to create another Object, say called Email__c, make sure it has an email field called Email_Address__c, maybe it has additional fields to make management easier (ex. a checkbox called Active__c), but most importantly, it has a Lookup to Contact. To make this new Object general, we should consider the possibility of adding Lookups to other Objects that we would like to track multiple Email (maybe Account?, some future custom object?).

Then to really make things general, we should probably make a Junction Object so that we can have a many-many relationship between Email_Address__c's and Contact's (so we can reuse Email Addresses). An idea I've been playing with is to save creating a whole 'nother Custom Object to hold Detail-records (I define a "Detail" record to be a record of a Junction Object), you could just house those records under a new RecordType for Email_Address__c called "Detail". So, all records relating to Email_Address__c are only Email_Address__c records, and those records come in (for now) only two Record Types: 'Email Address' and 'Detail'.

Hokay, now to go for the gold. To really, really save some data storage, let's store Email Addresses in a special way. Instead of creating a Custom Object to store an Email_Address__c, let's create an Apex Class called EmailAddress that has all the variables we need (a facsimile of what Email_Address__c's fields would be). Then to save the data, we will somehow collect the information in code so that we end up with a list<EmailAddress> for the Contact in question. Then, save the list as an attachment for the Contact. Here's a code-example:

public static string emailAddressAttachmentPrefix='EmailAddressList:';

id contactId;
list<EmailAddress> emailAddressList = new list<EmailAddress>();

// insert emailAddress's into emailAddressList
// . . .

Attachment emailAddressAttachment = new Attachment(ParentId=contactId,
                                                   Name=emailAddressAttachmentPrefix+'emailAddressList',
                                                   Body=blob.valueOf(JSON.serialize(emailAddressList)));
insert emailAddressAttachment;

Then, to access the data, we simply need to JSON.deserialize() it.

Attachment myEmailList = [SELECT id,Name,Body
                          FROM Attachment
                          WHERE ParentId=:contactId
                          AND Name LIKE emailAddressAttachmentPrefix+'%'
                          LIMIT 1];
list<EmailAddress> myEmailList = (list<EmailAddress>)JSON.deserialize(myEmailList.Body.toString(),type.forName('list<EmailAddress>'));

And as mention, to interact with the data, you'll need to create a UI to interact with it. I go about it by creating a Visualforce Component that deserializes the list<EmailAddress> and puts the data into a Wrapper class to display well. Then, in the VF Component, there's javascript methods (almost always using jQuery) that do any actions (add an Email Address to the list, delete a row, change the order, etc.). Then, I use a @RemoteAction method to save the list (which verifies the data is good, then it serializes the list up, and puts it back in it's Attachment).

After the component is built, make a new VF page for Contacts to display the EmailList-UI

<apex:page standardController="Contact" ...>
    <apex:detail subject="{!Contact.id}" inlineEdit="true"/>
    <c:emailList parentId="{!Contact.id}"
                 otherInterestingParameter=" ... "
                 evenAnotherInterestingParameter=" ..."/>
</apex:page>

Regarding this last method:

Pros

• A Contact can have an arbitrary amount of Email Addresses
• The list is stored as a JSON.serialized-Attachment
• Attachment data is not counted against Data Storage
• It's really easy to use the data in Apex (once it's deserialized)

Cons

• This list is maintained for each Contact, so we can't have a many-many relationship between Contact and EmailAddress (if we need this, the only option is a Junction Object (or RecordType as described above)
• We have to write our own UI to manage data (though the cost is only upfront, easily reused)
• Attachments do have a maximum size of 5 MB, so you may have to edit existing methods + add additional methods to watch out for / accomodate this limit (if you are close to breaching it).

---

That pretty much sums up all of my tricks on saving data storage space. To answer your question again, you can be as complex as you want to be. How much information do you want to collect? What are you going to do with the data you collect? What are the ways this data may be incorporated into in the future (but isn't incorporated now)?

Once you figure out how you want to use it, is the use case the most general case? Is there a clever way to generalize the problem at hand? ={D

Answer 2

Here's a different perspective, not as generalized as amatorVitae's solution:

SFDC fields of type Email have a couple of useful attributes:

1. They are validated by SFDC on data entry as matching a valid email pattern
2. They can be used in Workflow Email alerts when some update event occurs on the record containing the email field
3. SFDC will track bounces on the Contact object

It wouldn't be the end of the world to define a limit of 4 email fields on Contact:

• Email (the SFDC out of box field)
• Alternate 1 email
• Alternate 2 email
• Alternate 3 email

Using other fields on Contact, as @amatorVitae suggests, allows for point-and-click configuration of page layouts, search layouts, lookup layouts, validation rules, workflows, etc. if you need to decide between which email

Unless your Contacts are trying to hide from the government and have many email aliases; I would think that practically, your contacts wouldn't expect you to manage more than 4 emails.

Answer 3

My suggestion is as follows:

1. Create two Contact Record Types - Standard and Child. Limit the information displayed on Child to really email address only.
2. Add a look-up field to the Contact object - Standard Contact.
3. Add a new child contact to the standard contact where a different email address is needed. This has the Child record type.

With this in place, you can have different Contact roles associated with the different email versions of the primary Contact record.

If a new sales announcement goes to the version with an contact role of Sales and an email of [email protected]. The billing emails go to the version with a contact role of Billing and an email of [email protected]. But both are child contacts of [email protected]. You also can send email messages to the different contact records.

If you want to take it a bit further, you can use a trigger create log duplicate activities for emails on the master contact record. The trigger could also remove the activities on the child at the same time.

Also, all of the alternate email versions of the contact are displayed as a related list on the Primary.