6

We currently send all the error emails produced by our ISV package installed in customer orgs to a generic email list. The more packages we have and the more dynamic we assign developers to product teams the more inappropriate this approach gets.

I now thought of building a small app with an Email Service that basically receives, parses and assigns those errors to our internal processes.

Are there existing apps or best practices out there? Did you build something related and want to share some experiences?

3

We finally found this wonderful solution, which is part of the LMA Ext of the SalesforceFoundation.

enter image description here

It consist of an email service class which receives and parses the email and a custom object to store and report on it.

enter image description here

  • @jpmonette: If you like it please vote my solution up ;-) – Robert Sösemann Jan 15 '15 at 14:04
  • @RobertSösemann Did the regex expression worked for you? I tested this code against recent exception emails and the expression did not match, did you have to tweak it? Thanks. – PepeFloyd Mar 27 '15 at 11:44
  • @PepeFloyd no we had to completely rewrite it – Robert Sösemann Mar 27 '15 at 12:46
  • @RobertSösemann Thanks. That's what I thought : / – PepeFloyd Mar 27 '15 at 15:41
1

For our product, we built our own email alert system using Amazon Simple Email Services. We did this for the following reasons:

  1. The native Salesforce alerts are spotty. For some reason it seems that we only get an exception email like 20% of the time.
  2. We can add as much info as we need to the email, so we can include debug info that may not be in the out-of-the-box stack trace.
  3. Amazon SES is extremely cheap and I think you get a certain amount for free.
  4. Emails sent this way do not count against a customer's daily email limits.

Then we just have some email rules set up to route the emails appropriately as they come in. Since you have full control over the email, it is easy to add tags to parse and set up email rules for.

We did encounter a couple of gotachas. For example, you need to make sure you send the email from a future method. This lets you get around Salesforce rules that don't let you do a callout after you have performed a DML operation. Basically you build the email first, the serialize it, and send it to the future method as a string, deserialize, and send. You also need to have a fallback option in case you are in a method that does not allow callouts or future methods. In that case we generally send via the native Salesforce email method.

Hopefully this helps you out!

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.