Autocreating A Contact From Web To Case Or Email To Case - Story From: Popular Ideas
January 21st, 2012
Today's post is not for everyone. There's a very good reason why Salesforce.com does not autocreate contacts from Web To Case or Email To Case, and that reason is that one generally does not know enough about the person to associate him or her to an account. "Can't you just use the domain from the email address?" people often ask me, and the answer is no. If I get an Email To Case from somebody@yahoo.com, do I assume that person works for Yahoo? Probably not.
That said, there are Salesforce.com users who legitimately need to autocreate contacts in this way. If you're one of those users, then today's post is for you. Even if you're not, the trigger in today's post shows some solid techniques for bulkifying triggers, so if you intend to write Apex triggers, read on anyway.
The best way to autocreate contacts from cases like this is to use an Apex trigger. I'll post a link to the code here and then I'll explain what I've done.
The code and the corresponding test class is here, on the Developing With Service Cloud wiki. Be careful when copying and pasting that code to your own instance of Salesforce.com, as these wiki pages sometimes insert line breaks in strange places.
So how does this work? Let's examine the code a bit.
First of all, whenever you're writing Apex, you must bear in mind that these cases may be submitted in bulk, as many as 100 at a time. As such you have to be very careful about where you do your queries -- for example, it's rarely a good idea to do a query inside of a loop!
Web To Case and Email To Case both use the SuppliedEmail field (that's the API name of that field -- you can see it on your Case Page Layout as "Web Email") to try to identify the person who submitted the case. If the SuppliedEmail does not match the email address of any known contact in the system then Web To Case and Email To Case will leave the Contact field unfilled -- that's where our trigger comes in. There's another field called SuppliedName that stores the name the person entered for himself (or the name associated with the email address). We'll need that too.
So the first thing we do is make a list of the SuppliedEmail email addresses in the cases that have just been submitted:
List<String> emailAddresses = new List<String>();
//First exclude any cases where the contact is set
for (Case caseObj:Trigger.new) {
if (caseObj.ContactId==null &&
caseObj.SuppliedEmail!='')
{
emailAddresses.add(caseObj.SuppliedEmail);
}
}
Having done that, we can now find any of the email addresses that already exist. Why would we do that, you might ask? If the email address already exists as a Contact, wouldn't Web To Case or Email To Case have already associated it? Good question, there, reader. You're using your noodle. Normally, yes -- unless the email address is associated to more than one Contact! In that case the system doesn't know which contact to choose, and so it doesn't associate any contact to the case. We have to weed out any of the emails that are associated to multiple contacts, because this trigger also has no idea which one to associate to, so we'll leave those cases alone:
//Now we have a nice list of all the email addresses. Let's query on it and see how many contacts already exist.
List<Contact> listContacts = [Select Id,Email From Contact Where Email in :emailAddresses];
Set<String> takenEmails = new Set<String>();
for (Contact c:listContacts) {
takenEmails.add(c.Email);
}
OK, that's done. Note what I didn't do there -- I didn't do that query inside the loop of cases coming up, but rather I did it outside the loop, using the in operator in my query. That's good Apex practice.
Another thing you don't want to do inside a loop is a DML operation -- inserts, updates and deletes. I will momentarily be updating a bunch of cases, but it's a no-no to do that inside my upcoming (Read more...)
Categories: Salesforce CRM
