6

I have implemented email to case. Is there any possibility of stop creating case for bounced or out office emails as we are using same email address(routing address) as from address for workflow & approval email alerts.

  • Although not an answer to your question - your statement we are using the same email address(routing address) as from address for workflow and approval email alerts is what we avoided in our org to 1) ensure that we didn't have this issue and 2) provide better traceability to automated processes: a) email2case and b) workflows/approval processes so that if a Case was updated, we knew the true source business process. Essentially, xxx-support@mycompany.com and xxx-supportsys@mycompany.com – cropredy Apr 15 '14 at 15:27
6

Controlling e-mail to case is perfectly possible, but does require a level of Salesforce development knowledge/experience.

The easiest way is first, make sure you assign a Case Origin specific to e-mail to case (which I hope is basically standard practice)

Email to case settings page

With that in place, you can create a Trigger on case, for a before insert action, similar to this, to detect email2case cases about to get inserted, and check/block their progress:

trigger manageEmailCases on Case (before insert) {

    // go through our new cases and see if any email2case, "process" them
    for(Case thisCase : trigger.new) 
    {
        if(thisCase.Origin == 'Support Email') {
            /* Here's where to do your work
            if(thisCase.Subject.contains('OOO')) {
                thisCase.name.addError('Not saving e2c');
            }
            */
        }
    }

}

Now, with regards to what you put in the containing logic depends entirely on both your skill and organisational requirements, in my work, we have a custom object which represents a list of rules that allow/disallow email2case on a world of complicated facets. You could just hard code some known origins/subjects etc if you so wish.

You should note in this scenario though, you will want to be defensive of "swallowing up" cases with a bit of bad logic, and so it might be more apt to (instead of adding an error to block their insert) manage their fields, such as auto-close them, or add a "for review" flag instead?

I hope this helps.

  • I know this is really old, but any reason why you would not use a validation rule here instead of trigger? – Michael Gill Dec 2 '15 at 14:09
  • I guess only that a validation rule can only block insert, but the trigger approach (as alluded to in the last paragraph) lets you "do stuff" instead of just chucking the request out. You could do slightly more intelligent analysis on the fields/archive it away incase one day you wanted to dig up a potential mis-fire of the refusal rules etc.etc. where a validation rule would have just binned them out... (I think that's all true anyway!) – Simon Lawrence Dec 2 '15 at 16:28
2

This is an answer with some things added to Simon Lawrences post. I could not comment since I do not have the right numbers yet.

  trigger FilterEmailToCase on Case (before insert) {
  for(Case thisCase : trigger.new) 
    {
        if(thisCase.Origin == 'Email') {


            String subj = '';
            if (thisCase.Subject == null)
            {
                subj = '(No Subject)';

            }
            else
            {
                subj = thisCase.Subject.toLowerCase();
            }

            if 
            ( 
            (subj.contains('out') && subj.contains('office')) 
            )
            {
              thisCase.Description.addError('Not Saving Email 2 Case');
            } 
        }
    }
}

I used the previous example but then ended up getting emails with no subject which caused a null exception because Case.Subject was null. Above is the way I got around it. Very thanks to Simon for getting me on the right track.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.