Setting Up Internal IT Support with Email-to-Case

If I were a recipe blogger, I’d probably write about how I got into a snuggly sweater and curled up with a cup of tea and lovely set of Salesforce support docs to set up Email-to-Case this afternoon.

But I’m not that person, so I’ll just start writing.

The Business Problem

We needed a way to collect internal IT support requests. We used to have a a technology request form, but it was awkward to point someone to a form every time they had a simple question.

How We Solved It

We set up email-to-case to solve this issue. This was up and running in a few hours, which is a testament to Salesforce’s help docs and the awesome community.

In this post, I will detail some funny barriers I ran into setting up the creation of the support cases. We are currently trying to figure out how to communicate with users (e.g. case comments, carrier pigeon, etc.)

The way email-to-case works is that users send to an actual email address such as support@fakeorganization.org. You have your IT department set up forwarding so that when a person emails that address, the email is forwarded to a special Salesforce email (e.g. help@salesforce.blahblahblah.com), and that creates a case.

There are a few options that you can set up on Email-to-Case, such as default owner, what to do with files, and domains and email addresses that are allowed to create cases.

The main advantage to Email-to-Case is that it’s more similar to how someone might communicate with another person than, say, filling out a lengthy form.

The disadvantage is that we don’t capture as much data for routing purposes. For instance, moving forward, my manager and I will split up the systems we administer. When there is just an email (rather than a series of picklists), there is some manual case transferring that needs to occur.

As pre-work, I:

• Created an organization support email address – let’s say it’s called support@fakeorganization.org. I imagine this could also work with a listserv but I didn’t do it that way.
• Created a special record type called “Tech Request”
• Created each user as a contact in Salesforce with their company email in the email field (because of the way Cases work, this step was necessary)

I had never set up email-to-case before. I used the Salesforce help documentation to set this up so I won’t spend too much time detailing that.

I did run into a few hiccups along the way which I would like to share:

1. At first I was not able to verify the Salesforce email through Gmail. When you set up email forwarding through Gmail, there is an extra verification step. The system sends an email to the recipient email (so that would be help@salesforce.blahblahblah.com). Since that’s not a real email, this took some Googling. I eventually found this help article to set up Email Snapshots. I set up an email snapshot for that same help@salesforce.blahblahblah.com address and that allowed me to see my verification code.
2. I accidentally created a recursive loop by creating a queue with the same email address as we were using for help requests (support@fakeorganization.org), enabling email on it, and auto-assigning to this queue. Don’t do this.
3. Email signatures were looking very ugly and clunky when the cases were coming in. I fixed this by creating a process builder on Case that removes everything after the “–“:

1. Criteria:

AND(Not(Isblank([Case].RecordTypeId)),[Case].RecordType.Name = "Tech Request",ISNEW(),CONTAINS([Case].Description ,"-- "))

2. Field Update:

LEFT([Case].Description,FIND("--",[Case].Description)-1)

This will glitch out if someone includes “– ” in the body of their ticket. I also don’t know if it works anywhere except Gmail. But good enough. #rogueadmin

What’s Next

Next, we need to figure out a process for supporting users that is intuitive but also helps us track our work. Maybe we will even implement support metrics. Maybe there is a Service Cloud Cert in my future? Okay, I shouldn’t get ahead of myself.