Exceptions (Part 1) – When Things Go Bump in the Middle of the Night

What is an exception?

An exception is an error that disrupts the normal flow of code execution or flow execution. For example, attempting to populate a string field with a value longer than its maximum length, will result in a STRING_TOO_LONG exception.

In a perfect world, safeguards are put in place to handle exceptions as they are encountered. In the STRING_TOO_LONG example, a simple handling of the exception may be to abbreviate the string. By handling the exception, the process can continue as designed.

Processes with no safeguard in place are typically referred to Unhandled Exceptions.

What is an Unhandled Exception?

An Unhandled Exception is simply an exception that is raised, but with no safeguard in place to continue processing. As a result, Salesforce will halt the process and rollback the entire transaction. In addition, the transaction will generate an exception email.

Who receives the Unhandled Exception Email?

If the recipient(s) are not defined, the email is sent to the user that last modified the apex or flow. If your Salesforce instance is maintained by one user, this default behavior might be appropriate. However, in the majority of implementations, keeping the default behavior is a bad idea. Luckily, Salesforce provides a better set of options -> The Apex Exception Email and the Process Automation Exception Email.

Apex Exception Email

The Apex Exception Email configuration allows for the creation of an apex exception distribution list that can include users as well as external emails. This configuration defines where apex specific errors are routed.

Note: This is not the same as the User Send Apex Warning Emails option. The Send Apex Warning Emails options sends email notification when apex code surpasses 50% of an instance’s allocated governor limits.

Process Automation Exception Email

Within the Process Automation Settings, a configuration option exists for Send Process or Flow Error Email to. This should be set to Apex Exception Email Recipients. This points automations error to the same distribution list as apex.

Who should receive exception emails?

There is no single answer to this question. The answer will vary depending on the size of the organization, the DevOps process, and the number of instance administrators. My advice? Ensure the recipient(s) includes the correct list of individuals appropriate to triage, prioritize, and resolve issues as they are encountered.

That’s It? What am I going to do with all these emails?

If you are concerned about the volume, administration, and general reporting required to keep track of all these exception emails in your organization, let’s take a look at what an Exception Dispatcher can provide. Join us at Exception Emails (Part 2) – That’s It?.