Reply
Contributor
cjhouse13
Posts: 7
Accepted Solution

Best Practice - Moving to On Demand Email-to-Case

Hi All,

 

I'm in the process of designing an migration plan from the old Email-to-Case Java Agent to the new On Demand Email-To-Case.  Has anyone out there recently gone through this process?  If so, do you have any advice, best practices, things to look out for?  I want to make sure that I understand everything that this will entail and the best way to go about it before I present it to our IT Team.  They already resent having to support the Java Agent :smileyvery-happy:

 

Thanks in advance!

Courtney

Trusted Contributor
Mark Silber
Posts: 402

Re: Best Practice - Moving to On Demand Email-to-Case

I have experience moving 8 separate email agents that monitored 20 mailboxes from the on-premise Java based email agents to the new on-demand email-to-case functionality.

It works as advertised, and is very fast to process email messages compared to the minimum interval for the on-premise agents of 1 minute. I've seen emails show up in less than 5 seconds.

There are really only 2 things to be concerned with. First, there is a 10MB limit for attachments and an overall email message size limit. The online help and release notes can provide more specifics. In our case, this isn't a big deal, but I did have to leave 1 local email agent to process a mailbox that receives messages as large as 25MB.

Second, you need to work out your redirect strategy. I first thought I would be able to use local rules on each Exchange mailbox setup via MyMail to redirect the email to Salesforce. However, I discovered that Exchange rules setup this way that redirect don't preserve the original CC information. This means that when you look at the email message in Salesforce, it only shows the From and To addresses. If you use Exchange, you need to have your Exchange admin set the rules. When done this way, the redirect functionality does preserve the CC information so Reply All works as expected in Salesforce. You should also make sure you have rules setup to filter out out-of-office auto-replies and another other system generated messages you don't want to show in Salesforce.

Overall it's a great addition and removes the requirement for the on-premise agents. If you can live with the 10MB restriction and have a solid email admin to work with, I say go for it.

Let me know if you have any specific questions or additional concerns.
Contributor
cjhouse13
Posts: 7

Re: Best Practice - Moving to On Demand Email-to-Case

Thanks Mark!  I really appreciate your input.  I'll consider your notes and hopefully we'll be able to move to the new platform in short order!

 

Thanks again.

Courtney

Regular Contributor
jhamlet
Posts: 34

Re: Best Practice - Moving to On Demand Email-to-Case

I have been working on migrating our E2C service to the new on-demand service and have run into some issues with the Exchange Rules and Redirecting.

 

We seem to be unable to process a redirect from each mailbox... when I configure the rule to redirect to an exchange email enabled user that has the provided SF Email redirect address, then nothing is processed to SF.  When we enable the redirect on the Exchange Server, so everything is processed, then the emails show up in SF correctly.

 

However we need to configure exchange rules to keep the junk and internal emails out of SF.   Does anyone have any tips for setting up a redirect rule correctly in Outlook?  I have tried everything that I can think of (and found online) with little luck.

 

Thanks!

Trusted Contributor
Mark Silber
Posts: 402

Re: Best Practice - Moving to On Demand Email-to-Case

We no longer use rules to forward email from Exchange. We discovered that when you setup a mailbox rule to redirect email to Salesforce On Demand Email2Case, Exchange will not preserve the CC information when redirecting. We have a type of "distribution list" set up and all we do is add the external Salesforce generated email address as a member of this list so email is automatically sent to Salesforce.

 

I'm not sure why your rules aren't working. All your rules for filtering out junk and internal email should come before the rule that redirects mail to Salesforce. You should also have the option set on your rules to "Stop processing more rules" so it doesn't fall through the remaining rules and end up in Salesforce anyway.

 

Regular Contributor
jhamlet
Posts: 34

Re: Best Practice - Moving to On Demand Email-to-Case

[ Edited ]

Mark,

 

Thanks for the info... useful stuff.

 

Interesting solution using a distribution list.  That might work, but we would have to recreate all of our existing email boxes as distribution lists in order for this to work.  It is not an ideal solution and not one that SF has documented very well.  However, it would probably solve our problem with Exchange rules not working with a server side redirect.

 

Ideally, I would like to just be able to redirect emails to SF using outlook rules as that is the way that they intended this to work :smileysad:   I just can't figure out why the redirect works when it is enabled on the server and not when redirected from Outlook (configured from the mailbox).

 

 

Message Edited by jhamlet on 06-01-2009 12:37 PM
Trusted Contributor
Mark Silber
Posts: 402

Re: Best Practice - Moving to On Demand Email-to-Case

I agree that just setting rules using Exchange would be ideal, but unfortunately it is Exchange that isn't preserving the CC information on the redirect. We have always used distribution lists instead of mailboxes even with the on-premise version of E2C. Most of the distribution lists would all point to the same mailbox and then the email agent only had a few mailboxes even though there were dozens of distribution lists. E2C looks at the To and CC address to determine how to assign Cases, so the underlying mailbox didn't play a role. It was also easier to manage a small number of mailboxes versus dozens -- including not having to build and maintain all the rules on every mailbox.

 

Feel free to send me a private message if you want to discuss over the phone.