Admins / Service Cloud

Email-to-Case Best Practices: Case Assignment Rules, Queues & Auto-Replies

By Stacy O’Leary

Email-to-case is an out of the box Salesforce feature that allows your end customers to send an email to an alias, then have that email turned it to a support case. If you provide support to your customers, you might have something on your website that says “Need help? Just send us an email help@mycompanydomain.com”.

When you set up Email-to-case, you can take those emails and turn them automatically to Case records in Salesforce, send auto-replies, distribute them to your support team, and take other automated actions. These will save support teams a lot of energy creating Case records and managing them appropriately. Instead, you have the chance to free up the team’s time to focus on the Cases that really require intervention.

These are a few best practices that can help improve your use of Email-to-case and Case Assignment Rules.

1. Who Can Use Email-to-case?

Decide which external users (customers) should be allowed to send emails that generate Cases.

The bad news: You can’t actually blacklist email addresses from sending you an email. What you can do, however, is create a validation rule blocking the creation of any case that meets certain criteria:

The customers aren’t going to see that error message, but it can help later when troubleshooting, or for any future Admin trying to figure out what this validation rule is for!

2. Set up Queues with a Catch-all Queue

Imagine that a company has three Service Levels (Standard, Premier, Premier Plus). The “Standard” Service Level will serve as the catch-all for anything that is not Premier or Premier Plus.

If you don’t use a catch-all, then Cases could end up assigned to the default user instead. Your support team might not see them and won’t be able to resolve them in a timely manner.

3. Send Auto-replies with the Process Builder

…and don’t send auto-replies to emails with certain subject lines.

When a customer sends an email to your support alias, they are likely going to expect a reply. You might even be required to provide one, depending on how your SLAs are worded.

Salesforce has a section in the Support Settings where you can add an email template for all auto-replies to cases. I don’t recommend using this, because you cannot control who gets an auto-reply, and who does not.

You may think that everyone should get an auto-reply, but that’s not the case. Some people have vacation notices turned on, or they have auto-replies on their own email box, which can cause a case-looping problem. That’s a nightmare because you’ve got two email auto-replies just spamming each other back and forth!

I prefer to send an email reply out with the Process Builder, and only for emails that meet a certain criteria:

  • Subject does not contain Out of Office, OOO, out-of-office, vacation, PTO, paid time off, holiday
  • Web Email does not contain @mycompanydomain

Remember: it is an email address and anyone can send to it, so you don’t want to send an auto-reply for Out of Office emails, or perhaps employees at your company.

4. Add the Case Feed ID to the Case Email Templates

One of the coolest features of Email-to-case is that a customer can reply to your support email alias, and as long as the Case Thread ID is somewhere in the email, then that email will update the existing Case (rather than create a new case).

Now, you can’t force your customers to copy and paste the Case Thread ID into an email – but, if they reply to an email that already has that value in the text, then no one has to do anything!

I always recommend to update all of your Case Email Templates with the Case Thread ID in a white font (or black, if you don’t mind the customer seeing that value).

5. Sort Cases Based on Case, Contact, or Account Fields

Case sorting works on a set of rules you build and will sort in the order you provide. So, it helps to think of your most important cases first, and then sort in that order.

Case Assignment Rules are going to look at the Web Email of the person who has sent the email and match them to a Contact Record. If that person has a Contact record, you can then sort their Case based on any value on the Case, Account, or Contact. If that person does not have a Contact Record, all you can sort on is the information you received, the Subject, and their own email.

I have two rules for Premier Plus, and two rules for Premier, so that you can see this a little more clearly, but in practice, you can combine them with some OR logic.

For Rule #2, if any person sends an email with a Subject that contains “emergency” it will automatically be routed to the Premier Plus queue (even if that person is not a Premier Plus customer.)

Study your SLA’s carefully, and consider the types of emails you will receive before you begin building. As always, add that catch-all at the end with no criteria, just to make sure nothing slips through the cracks.

Bonus Tip: Familiarize Yourself with the Support Settings

In Tip #3 I briefly mentioned Support settings. This is a long page in your Setup Menu with a whole bunch of options, that can be toggled on and off. I’ll save the details of each feature for another post, but make sure to do your research on each of these before filling anything out or changing the default settings. Making a mistake here could have major repercussions that are customer-facing, so use caution, and as always, test in Sandbox first.

I hope this helps you implement or improve your Email-to-case! Do this right and your support team will be grateful, and hopefully, your support team will see an immediate reduction in “busy work” of distributing cases. They’ll be able to focus on the cases that need resolution and prioritize much more accurately, and hopefully a faster time-to-resolution and improved customer satisfaction!

The Author

Stacy O'Leary

Stacy is a 5x Certified Salesforce Consultant & Full Time Mom.

Comments:

    Dominitz
    August 13, 2020 11:52 am
    Any suggestion for handling an email from an unrecognized email address or domain? I assume that the sender is a valid contact but didn't dent the email from an address that is listed in the contact's email field
    Ed
    October 15, 2020 3:27 pm
    Ben, this is really helpful. How do you accomplish this in PB? Subject does not contain: Out of Office, OOO, out-of-office, vacation, PTO, paid time off, holiday
    Leonardo
    October 19, 2020 12:19 pm
    Ben, how can we do step "4. Add the case feed ID to the case email templates" with the winter update 21 to email the case's threading ID? I did the same thing in a client organization, I found the update via header instead of the id via text very nice. But now when a new case is created and I send the email via process builder, it looks like Salesforce doesn't add any header linking that email to the case that triggered the PB, so if the customer responds to the automatic email case creation, a new case is created within Salesforce. Do you have any idea how I can get around this, except to disable the update (which in summer 21 will be mandatory)?
    Leonardo
    October 19, 2020 12:42 pm
    An update here. The Salesforce attachs the header in auto response rule e-mail model only, if you use PB you will miss this feature =/
    Leonardo
    October 19, 2020 1:51 pm
    Ben, how can we do step "4. Add the case feed ID to the case email templates" with the winter update 21 to email the case's threading ID? I did the same thing in a client organization, I found the update via header instead of the id via text very nice. But now when a new case is created and I send the email via process builder, it looks like Salesforce doesn't add any header linking that email to the case that triggered the PB, so if the customer responds to the automatic email case creation, a new case is created within Salesforce. Do you have any idea how I can get around this, except to disable the update (which in summer 21 will be mandatory)?
    grace marrese
    March 15, 2021 4:35 pm
    Hey Ben! With the Thread ID now being depreciated - how do we enable users responses to be added to the case that was already created via email to case if they respond to the email alerts triggered via PB instead of creating a new case? For example... - User emails the email-to-case email address - User receives " Your case has been created" email alert generated via PB - User responds to this email - right now its creating a new case instead of being added as an email reply to the already existing
    Naveen Mosuru
    June 28, 2021 3:43 am
    Hey did you find the solution to this issue,Please let me know asap. Thanks.
    Shayla
    October 01, 2021 8:33 pm
    Is there a way to assign a a category to an alias?
    Shweta
    February 12, 2022 7:55 pm
    Hi Ben, I am trying to assign queues on the basis of contact /account field on case for example if contact name on case is blank assign queue a and if it is not assign queue b. I wrote a logic on before insert but it is not working. assignment rule is also not working with this condition. I set the field tracking for account on case and see , first Case is created first and than Account on case is updated if the case is created from the email and the contact->account exists with that email id.Please let me know if there is any solution for this ? Thanks
    Tabatha
    March 18, 2022 8:38 pm
    Did you get this figured out? I am just setting ours up and noticed this problem.
    gina
    April 07, 2022 2:02 pm
    We have 6 different client facing email distribution groups(billing, customer service etc). Our client tend to blanket numerous emails distribution groups when submitting a request. How do we prevent multiple cases from being created. Can we set up a rule that says that if more than one of these 6 email addresses are in the thread then assign this email to this Que and only insert 1 Case?
    Casey
    October 27, 2022 7:32 pm
    We addressed this in our org by creating a custom text field on the EmailMessaeg object called something like "Unique Message ID" and setting it up as a unique field. Then we created a before update trigger that copies the data from a field named "MessageIdentifier" (note that this field doesn't appear in the object manager UI). Our email system is Gmail and we found that emails sent to multiple Gmail addresses all have the same value in the "MessageIdentifier" field. Copying this value over to the custom field and having the custom field be unique has worked at preventing duplicate cases because the email records with the same ID beyond the first are prevented from being inserted.
    appertain
    October 31, 2023 3:46 pm
    There is definately a lot to ⅼeаrn about this suЬject. I love all the points yօu made.

Leave a Reply