Let’s Have Some Fun with a Reclusive Teenager and Email-to-Flow Salesforce Exception Handling
August 31, 2023
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.
Provide dinner notifications to a reclusive teenager.
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 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 MAX7219 LED display driver
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.
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: