Let’s Have Some Fun with a Reclusive Teenager and Email-to-Flow Salesforce Exception Handling

Introducing the Sproket Logic Urgency Box.

Introducing the Sproket Logic Urgency Box.

What’s the Sproket Logic Urgency Box?

The Urgency Box was originally conceived with one goal in mind… notify a reclusive teenager that it was time for dinner.

The Goal:

Provide dinner notifications to a reclusive teenager.

Communication Challenges:

The following communication challenges would be resolved or reduced

  • Yelling up the stairs to the teenager’s lair
  • Reliance on the cell phone
  • Receiving the dreaded “…in 5 minutes” response

Thus, the urgency box was born.

The Urgency Box providing an informational message

The Urgency Box is a simple box placed within the Teenager dwelling which includes:

  • A display to provide specific and accurate information/instructions
  • An urgency signal to indicate the requested response level
  • An annoyance factor to elicit proper responses

How does it work?

The box is simple enough. The box contains a number of components including

  • 12V LED signals
  • 5V relays
  • 5V MAX7219 LED display driver
  • ESP8266 NodeMCU
  • Arduino UNO

The ESP8266 NodeMCU acts as a web server acceptng commands. A communication payload (including the message, the urgency, and annoyance factor) is processed by the web server. Those commands are sent to the Arduinio UNO for display.

The message is presented on scrolling display matrix. Ther urgency translates to the led signal. Each signal is activated by a relay (making a great annoying clicking sounds as the signal is activated and inactivated). The annoyance rate translates to the blink rate of the signal.

Various advanced options are also available for the reluctant teenager including Panic mode.

The Urgency Box in “Panic 1” mode.

Cool, but what does this have to do with Email-to-Flow Salesforce Exception Handling?

Well, I was recently thinking, the Urgency Box can just as easily be leveraged for the unaware Salesforce administrator as it is for the reclusive teenager. But I’m getting ahead of myself. Let’s start with a quick look at Salesforce Exception Handling.

What is an Exception?

An exception is an unexpected event, which occurs during the execution of a program, that disrupts the normal flow of the program’s instructions.

For example, a client has the following business requirement:

On Opportunity Closed Won, create a new project. Set the program name in the format of Account Name + ‘-’ + Opportunity Name.

If the result of the Account Name + ‘-’ + Opportunity Name exceeds to size of the Project Name column, a STRING_TOO_LONG exception will be thrown.

What is Exception Handling?

Exception Handling is the process of responding to exceptions as they occur. While there are many variations of exception handling, they generally fall into three categories:

(1) Code specific logic to prevent to occurrence.  For example, leveraging the allowFieldTruncation property to truncation string fields on DML.

(2) Method specific logic to catch and handle the specific code blocks exception.  For example, leveraging a Try-Catch-Finally statement to catch the String-Too-Long error and manipulate the string according to specific business logic.

(3) System specific error handling to process unhandled errors.  In the event that neither a code specific or method specific error is handled, a system specific process handled these errors. In Salesforce, unhandled exceptions are processed via Exceptions Emails.

What are Salesforce Exception emails?

When unhandled exceptions occur in Salesforce, an email is generated that includes the stack trace, exception message(s), and additional origination information. By default, these emails are sent to the developer specified in the LastModifiedBy field on the class, trigger, or flow. This default behavior can be overridden by configuring recipients via Apex Exception Email and Process Automation Settings.

Awesome, so Salesforce already provides everything we need?

Well, yes and no. For some small Salesforce instances, an email may be enough. However, in larger instances with multiple support teams, an email approach can be cumbersome.

This approach lacks many of the capabilities you typically expect in an exception handling. Here are just a few:

  • Logging – Logging errors to a specific data store (such as creating a support ticket) provides the ability to report on issues and assign issues for repair.
  • Enrichment – Enrichment provides the ability to add additional context to the exception include information such as a classification and an urgency. For example, this exception is related to the Account integration which is a critical process and needs immediate attention.
  • Suppression – The ability to suppress exception logging. For example, a batch process failure was identified earlier in the week. Additional exceptions should be associated to the existing ticket rather than opening a new ticket.
  • Routing – In the existing Salesforce model, all users configured in the Apex Exception Email will receive the exception emails. In large organizations, duties might be segmented by different administrators, teams and/or skills.
  • Reporting – Any basic unhandled exception solution should be able to provide reporting.

I’ll bite! How can I transition from basic Apex Exception Emails to a full Unhandled Exception Handling?

Based on your specific requirements, there are a number of applications which provide an error logging mechanism. To name a few:

There are several Cloud based error tracking options including Rollbar | Error Logging & Tracking Service for Software Teams and Datadog Error Tracking | Datadog (datadoghq.com).

There are several Issue/Project tracking apps such as Jira | Issue & Project Tracking Software | Atlassian.

And of course, Salesforce case Management is a great option.

Regardless of the application end point, you will need the ability to route apex error notifications to a process that can parse and process these exceptions.

Let me guess… Email-to-Flow?

You got it! Email-to-Flow is the secret ingredient.

(1) Create a new email service email address.

(2) Route apex and flow exception emails to the email service email address.

(3) Leverage the power of Email-to-Flow to parse and process exceptions notifications.

Interested in building out your own Exception Handler, we would love to help. Give us a ping.

Wait a minute! Where does the Urgency Box come into play?

For a little fun, we hooked up the Urgency Box to an existing client’s Email-to-Flow Exception Handling routine and Walla! Never miss an exception notification again.

The Urgency Box reporting a Salesforce unhandled exception.