Getting Started with Email-to-Case
This is the second in a series of Getting Started blogs about the Service Cloud. In these blogs I’ll be introducing some standard service features and talking about how you can get set up with them quickly. I’ll also mention some tips and tricks I’ve found from implementing these in the past, and any limits or ‘gotchas’ that you should be aware of.
You can find my first blog, Getting Started with Web-to-Case, here.
What is Email-to-Case?
Email-to-Case allows you to generate a Case automatically when a customer emails in. It also populates some Case information automatically, saving manual effort – for example, the email subject becomes the Case Subject, and the email body the Case Description. You can configure more than one Email-to-Case channel if your organisation has multiple support email addresses and processes.
When should I use Email-To-Case?
The short answer: you should be thinking about Email-to-Case if any part of your email support process includes the words ‘copy’ and ‘paste’.
The long answer: you should use Email-to-Case if you have one or more support email addresses which agents handle manually, for example if they are currently working out of the mailbox itself. You should also consider Email-to-Case if your current support process requires any manual logging of issues, for example on Google Docs, or by manually adding email content to a Case.
Why are there two types of Email-to-Case? Which should I use?
On-Demand Email-to-Case is a simpler version of the old Email-to-Case, and is what I generally recommend. It’s easier to set up since it doesn’t require the installation of the Email-to-Case agent behind your firewall. It also doesn’t contribute to your API usage when creating Cases. (When it first came in, it was known as ‘Email-to-Case as a Service’.)
However, On-Demand Email-to-Case has two key restrictions:
- It will only handle attachments from customers up to 10MB
- It doesn’t keep email traffic within your firewall
How do I get started?
Decide which version you want to use. If the restrictions I mentioned above are a deal-breaker, you might want to use Email-to-Case with the Java client installed behind your firewall. Click here to learn how to set this up.
If you’re OK with the restrictions, and you’ve decided to use On-Demand Email-to-Case, the best reference guide to doing this is Salesforce’s help article, Setting up Email-to-Case.
Whichever option you choose, after you’ve completed the technicalities, you still have some design decisions to make. I’ll talk about these in a little more detail below.
Tips and Tricks
- Linking Cases to Contacts
A nice feature of Email-to-Case is that new Cases will be linked to the relevant contact and account automatically wherever possible. This is based on the email address your customer is sending from: if Salesforce recognises their email address as that of an existing contact, it will link this contact and their account to the new Case.
There are some considerations here if you are storing more than one email addresses per contact, or if you have duplicates. I go through these in my earlier blog, Getting Started with Web-to-Case.
The bottom line is that this feature will help you to build good data on your customers and their support history, but it won’t work in all cases, and you should support it with manual or bespoke automated processes.
- Email Threading
Email Threading is an important part of any Email-to-Case setup. Setting this up essentially means that, if a customer emails you more information about an existing Case, their second email will be attached to their existing Case instead of creating a new Case.
This works by adding a unique ‘Thread ID’ into your Auto-Responses and other outgoing emails, so that any later email responses can be linked back to the right Case automatically.
Image showing Email Threading options in the Email-to-Case setup
As you’ll see from the image above, your Thread ID can go into the Email Subject, or the Email Body, or both.
I’d recommend adding both, since some email clients will cut off your original message when composing a reply. However, I’ve spoken to customers who have chosen not to add the Thread ID into the subject line on the grounds that it looks ugly. If you do this, (or if you’re considering not adding the Thread ID at all!) just bear in mind that you’re at risk of creating duplicate Cases, which will send duplicate Auto-Responses to your customer and will likely increase your agent effort as a result.
In short, you can see the Thread ID as a trade-off between cosmetic appearance and the efficiency of your support organisation.
As of Winter 15, a Thread ID becomes even more relevant, since Salesforce has extended Auto-Response emails so that they get sent to all contacts CC’d on your customer’s original Case. If one of these CC’d contacts email your agent in response to the Case, Email Threading helps these emails get linked back to the Case.
- Handling multiple email addresses
3.1 What if I have more than one email channel?
No problem: it’s possible to have multiple Email-to-Case configurations. You configure these separately, which allows you to define a different Priority, Origin and Case Record Type in each case. (And, as a result, you can also apply different Auto-Responses, Assignment Rules, and other automation).
I’d recommend this approach if your email addresses correspond to different support processes, for example if you have a tech support address and a general enquiries address.
3.2 What if I have more than one email channel with a similar support process?
If this is the case, you might want to handle both email channels as part of the same Email-to-Case setup. You can do this by simply forwarding both email addresses to the same Email Service Address (read more about this in Salesforce’s help article, Setting up Email-to-Case). This will reduce your administrative effort.
This would be a good approach to choose if you have different email channels with a similar case management process – if, for example, the same team picks up emails to email@example.com and firstname.lastname@example.org. This is because the solution works best if both email channels are subject to the same Auto-Responses and Assignment Rules.
- Enriching the Case using Email-based information
I mentioned earlier that Email-to-Case automatically populates your Case with the contents of your customer’s email. Another great benefit of Email-to-Case functionality is that you can enrich your Cases further using from the email, using workflow rules that you define yourself.
This is because Salesforce’s EmailMessage object has a tight relationship to Cases and supports cross-object workflow. This gives you a number of options for taking information from a customer’s email and adding it to the Case, which can makes it easier for an agent to pick up the Case and resolve it quickly. I have two examples below.
Example 1: Updating the Case based on an email’s TO Address
Scenario: You have two email addresses hooked up to the same Email-to-Case channel, but you want to show on the Case which email address the customer sent their email to.
For example, email@example.com and firstname.lastname@example.org are both forwarding emails to the same Email Service Address. However, the agent who picks up the Case needs to see quickly which email address the customer originally contacted. Your agent looks at a picklist field called Support Email to see this information.
Solution: You can set up an EmailMessage workflow to copy this information onto your Case. This will update the Support Address picklist on the Case to show ‘Enquiries’, which shows the agent that the customer’s email came into the enquries@ address.
Image showing the Support Address workflow formula
This workflow formula does two things:
- It checks if the address the customer emailed to was email@example.com
- It checks if the email was the first one for the Case (we only want to update the Support Address picklist for the original email)
After adding this formula into your EmailMessage workflow, you can then add a Field Update to update the Support Address picklist on the Case to show ‘Enquiries’.
You can then repeat the steps above to identify emails sent to the firstname.lastname@example.org address and update the Support Address picklist to show ‘Feedback’.
NOTE: this solution is not recommended if you need to identify a larger number of Support Email options, since each one requires a new workflow. (Your workflow limit is 50 per object.) If you have a larger number of Support Email options to handle, consider using APEX code to handle the assignment of all your Support Email options together.)
Example 2: Highlighting new responses to an existing Case
Scenario 2: You want to make it obvious to your agents when a new customer email comes in regarding an existing case. These can often be missed by the agent handling the case, which can lead to delays in case resolution and frustration for your customer.
Common ways of handling this can be to update the Case Status when a new email comes in, or to add a ‘new email’ flag to the Case. You could also configure an email alert to notify the Case Owner.
It is worth taking time to consider which solution fits best in your organisation’s case management process. Whatever you decide, the solution below is a good start to any one of these solutions.
Solution: There is a useful checkbox on the Email that we can use to detect new messages. This is a checkbox called ‘Incoming’, which shows when an email has come in (from a customer) or when an email has gone out (from an agent). This checkbox will be ticked (or ‘TRUE’) when the email is incoming; it will be unticked (or ‘FALSE’) when the email is outgoing.
Image showing the Incoming Email workflow formula
Simple! As before, you can use this formula in an EmailMessage workflow. You can then copy this information onto your Case, using a field update, or trigger an email alert to notify your agent.
My preferred solution is to add a checkbox to the Case which I tick using a field update. I then add this to the Case page layout, and to Case list views, so that agents are made aware of the new emails.
Sophisticated Email-to-Case handling
Although these workflow examples are good for enriching Case information, this information shouldn’t be included in your criteria for Assignment Rules or Auto-Response rules. This just won’t work. (This is thanks to Salesforce’s Order of Execution rules, which means that your your Assignment Rules and Auto-Responses will already have fired before your workflows have been processed – oops!)
If you do have email information that needs to be included in your Assignment Rule or Auto-Response Rules, you could consider using APEX code, or breaking these email addresses out into separate Email-to-Case channels (if applicable). Remember that each Email-to-Case channel can define different Priority, Origin and Case Record Type options, and you can use this information to trigger Auto-Responses and Assignment Rules.
If you need advice on your own scenario, feel free to get in touch below.
- Remember that when a Case is created by Email-to-Case, it will always show as ‘Created By’ the Automated Case User you have specified in your Support Settings. The default owner will be your nominated Default Case Owner. You can change both of these settings in setup (Setup | Customize | Cases | Support Settings).
- On-Demand Email-to-Case has a daily email processing limit of 1000 emails multiplied by your number of user licenses. For example, a 50-license org will be able to process 50,000 emails daily. This is capped at 1,000,000.
- If you are using Case Record Types, remember to give your Automated Case User access to any Record Types you have associated with your Email-to-Case channels. If they do not have access, they will not be able to create new Cases for that channel.
- If you are using On-Demand Email-to-Case, the maximum email attachment size is 10MB.
- Standard validation rules will still run when Cases are created by Email-to-Case, and universally required field settings will also apply. Make sure that you test your Email-to-Case configurations before adding your forwarding addresses, and check over your existing Case validation rules to make sure that they’re not going to conflict.
- Email-to-Case should not be misused as a method of integration from other systems. Wherever possible, if you are sending structured data over SMTP as the only option, we recommend using an Apex Email Listener instead of Email-to-Case.
- Email-to-Case is available for Professional Edition and above.