Report Failure to SightLane

If you've read the Flow Audit Overview article, you know that creating visibility in your Salesforce Flows is as easy as drag-and-drop. In this article, we will look at another of the five SightLane Flow components: "Report an Event Failure to SightLane."

Create an Event Log Collection Variable

As in all Flows, we begin by creating an Event log collection variable (unless you are using Text Templates).

Once this variable is created, we can add to the Event logs at any time, via standard Flow Assignment elements or other SightLane Flow components (for example, the "Log Record Data" component).  

Using the Report Event Failure to SightLane Component

As mentioned in the Flow Audit Overview article, the "Report Event Failure to SightLane" component is responsible for documenting the details (logs) from a single execution of a Flow.  It is the component used to save all audit/log data to the SightLane platform.  To use this component, drag an Action component onto the screen and select the "Report Event Failure to SightLane" action. Then, set a few attributes.

Pro Tip #1: With SightLane, reporting Flow failures by defining a fault path can be an unecessary step.  Since SightLane AutoCapture will automatically catch and report Flow Failures (including all the juicy data details), we often don't have to trap faults at all, unless we are designing a custom fault path.

Pro Tip #2:  The Report Event Failure to SightLane component is not just for technical errors.  If the logic of your flow behaves in a way that is unexpected or considered a logical failure, you can use this component to indicate a business process failure (even though a technical error did not occur).

The Report Event Failure to SightLane component holds seven attributes that control how the monitor is created and what content is saved.

SightLane Monitor Name - This is how you will name the monitor under which this Event will be saved.  It is possible to save documentation from multiple Flows under the same Monitor.  A common practice is to name the monitor after the Flow for which it creates visibility.

Event Id - Gives the event a specific and (potentially) unique id.  In this way, we can separate individual executions of the event.  A common practice is to use the Flow's Interview Guid as the unique identifier, but if you have a more meaningful way to populate the id, go for it!  If an Event Id is not specified, SightLane will generate a unique Id for you.  In other words, this is optional.

Primary Record Id - allows monitors to "associate" an Event with a particular data record.  If there is an issue during an Opportunity update, it sure would be nice to know which one!  In addition, this will enable seamless navigation between the Event log and the affected record, making research and review much faster.

SightLane Log - When using Text Templates, add your TextTemplate variable to represent all log data captured during this flow.

SightLane Log Delimiter - When using Text Templates, this represents the character(s) used to separate lines within your Text Template content.  Each line will be logged as a separate line in your SightLane Event.

SightLane Logs - When using a Text Collection, this represents all the logging content produced and captured during the Flow.  Add your Log Collection Variable as the value. 

Hint:  If your Log Collection Variable is not showing up, you may have forgotten to check the "Allow Multiple Values" checkbox when defining your logging collection variable.

Summary Message - This is a short description of the Event's outcome, such as "The event encountered a Divide by Zero error" or "A new Opportunity was successfully created."  The choices are up to you.  This value will appear in notification emails and can be a great early indicator to Admins and developers of the current situation.