0

Cannot find any example of guide to this either here on in SF's "help"...

When using Email-To-Case, is it possible to add (workflow I would assume) a value to other field(s) on the Case when it's or after it's created?

Example:

We have three different "Refund" email addresses, specific to three different products. We want the Case Record Type to be Refund, but the Product__c field to be the name of the product. In Email-to-Case, you can only define the Record Type (and Priority, Origin (email) and create a Task).

I have a WORKAROUND I'll use if there is no way, but it's queer. I would create a transitory Case type (Temp XYZ Refund) and assign Product XYZ refund emails to that Record Type... then workflow/field update the case to Refund type AND set the field(s) I want. I'd rather do it in a more appropriate way (if it exists) without writing Apex.

I'm also tempted to tell the Company we're going to have multiple Record Types (Refund XYZ, where XYZ is each product allowing refund requests via specific emails).

Thanks!

Improve this question
2
  • This would be something very achievable with an Apex Trigger (in fact, I've done very similar in the past) but you state you are looking to do this without Apex, correct? (Working with Professional Licences?)
    – Simon Lawrence
    Mar 19, 2014 at 20:43
  • Just about anything is achievable via an Apex trigger. However, I do not subscribe to the belief that an SF Org needs to be complicated by Apex when it is possible via GUI only, so I always look for even remote non-Apex solutions first before deciding to commit to Apex.
    – AMM
    Mar 20, 2014 at 11:44

1 Answer 1

Reset to default
6

Rather than creating "dummy" record types, which seems like a heavy handed way to identify the different incoming Email2case types, why don't you add different case origins to the picklist, and set three of these?

If you navigate to

Customize > Cases > Fields > Case Origin

Case Origin

you could then add three new values to the picklist

Refund X Refund XY Refund XYZ

new values

And then in your Email2case setup (which you seem well familiar with) set the different Case Origin fields for the three e-mail addresses. You would then go ahead with the workflow rules you outlined (so again, I assume familiarity) to detect a new case being created with a Case.Origin of "Refund X" and do a field update to set the Product__c field to what you want?

If case origin being "Email" is then important to you still, you can of course add a second field update to set that back to a traditional value?

It is basically still using your approach of seperating the sources of the Emails, but Case Origin seems like a more appropriate (it's in the name!) way of doing this.

Improve this answer
1
  • I keep looking at Origin, and keep thinking along these lines.. but was continuously affected by it's existing values (including a singular "Email" origin). This IS a logical solution though. :-/ I'm going to have to consider this more seriously, because (idea sprouting..) even then, I could use the Origin TO STAMP to the Product, then RESTAMP ORIGIN to EMail (if it's crucial to existing parties here). OKAY, that actually seems good.... going to pursue this.... thanks.
    – AMM
    Mar 20, 2014 at 11:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .