Salesforce Flows & How to Debug Them

During Dreamforce, Salesforce shared updates and information about the migration to Salesforce Flows. In this article, we’ve assembled a guide to help you understand why this shift is important, and to learn specific ways you can debug flows.

Why Salesforce Flow?

With the most recent releases, there has been a large investment in enhancing the features of Salesforce Flow. Also, you may have heard about the impending retirement of Workflow Rules and Process Builders, with Salesforce releasing tools to help migrate these features to Salesforce Flow. The main reasons for this update are: each tool having overlapping capabilities and business automation needs are becoming more complicated. The need for more sophisticated tools means that Salesforce made the decision to focus on enhancing Salesforce Flow, instead of maintaining and enhancing three separate tools. 

So what does all of this mean? Salesforce Flow is now the go-to tool when thinking about the implementation of declarative automation development. Salesforce has been investing a lot in Salesforce Flow over the past couple of releases, which makes this tool a lot more powerful and more appealing to developers with fresh abilities to: 

• Run Processes Asynchronously 
• Perform Fast Field Updates (Before Save) or Update Related Records (After Save)
• Handle complex Process Entry Conditions such as formulas
• Provide better error handling, troubleshooting, and debugging. 
• Exceptional extensibility with Invocable Actions and Sub-Flows for repeatable and reusable functionality.
• Provide user interfaces through Screen Flows
• Direct work items to the correct resources with Omni-Channel Flows 

Main Types of Salesforce Flows

1. Screen Flow

A flow can be called using a button or an action or displayed in a Lightning Page or the Utility Bar. Once actioned, it appears as a screen for the user to interact with. Screen flow cannot be automatically triggered.

2. Record-Triggered Flow 

This flow is based on triggering conditions of a record in Salesforce. Record-Triggered flows are comparable to Process Builders in that they can only be aligned to a single object. However, they can be launched when a record is created, updated, or deleted. They can also be configured to start based upon declarative entry criteria, or a formula evaluating to true. Record-Triggered flows can be run before or after Save context to support updating the originating record or related records respectively.

3. Auto-Launched Flow 

These flows are very similar to Record-Triggered flows but can be invoked from other areas of the platform such as Apex, a Process Builder, or even another flow. Auto-Launched flows are useful for performing actions automatically behind the scenes which may or may not require some action from a system user. 

4. Scheduled-Triggered Flow 

A Scheduled-Triggered flow, as the name suggests, runs automatically based upon a recurring schedule configured by the Admin. It is helpful for jobs performed frequently or on a schedule (once, daily, weekly).

5. Platform Event-Triggered Flow 

These are called when a platform event is received in the system and are used to perform operations within the org based upon the received platform event.

6. Omni-Channel Flow 

A flow capable of using out-of-the-box actions to support the routing of work items to service resources based upon defined criteria. These flows can use all the same mechanisms as a Record-Triggered flow to make smart routing decisions for complex business needs.

How to Debug Salesforce Flows

Option 1: Debugging on Canvas 

The most used method of debugging flows is directly on the Flow Builder canvas. For each type of flow mentioned above, other than the Platform Event Triggered flow, once a stable version of the flow has been built the author will see a Debug button at the top of the canvas. Upon clicking this button, the user will be able to provide the details of any entry criteria that may be required, such as a Salesforce Record ID, or by looking up a specific Salesforce record with data that may trigger an action within the flow. This all depends on the nature and operations of your flow.

Once the entry criteria is provided, the user will be able to run the flow with the provided data and monitor the progress of the flow as it runs through each of the steps, providing the author with detailed information on how variables and records are being processed throughout. For a Screen flow, you can walk through each screen and provide inputs to test the flow before releasing it to users.

While running the flow in Debug mode, the author has many different runtime options which are driven by the type of flow being debugged as can be seen below:

Record-Triggered Flow:

• Run as another user
• Provide Input Conditions
• Run in Rollback mode
• Skip Start Conditions
• Run Immediate Path or Run Asynchronous Path

Screen Flow:

• Run as another user
• Provide Input Conditions

Scheduled-Triggered Flow:

• Debug Pause Element
• Run in Rollback mode

Auto-Launched Flow:

• Run as another user
• Provide Input Conditions
• Debug Pause Element
• Run in Rollback mode

Omni-Channel Flow:

• Run as another user
• Provide Input Conditions
• Run in Rollback mode

Option 2: Debugging Via Flow Error Email/Failed Flow Response

The next way to Debug the flow is to take action at the time an error on the flow occurs. By default, the user who last worked on the flow will receive an email when any user in the system encounters an error with that flow. This can be updated in Process Automation Settings to send the error email to all Apex Exception Email recipients, should you require more visibility into flow errors.

However, depending on your settings what the recipient will receive is an email from Salesforce support outlining the runtime of the flow and which specific element the flow failed on, and some small details about the cause of the error, such as Incorrect ID type and Unexpected Null Value, which the admin can then use to figure out the issue with the flow. Alongside this, the email will also contain a link to the failed flow version which will redirect the admin to the flow canvas for the failing flow. This will allow them to get a visual representation of the error and review what happened at each element of the flow to capture where the error occurred and provide a fix. 

These failed flow versions can also be accessed from within Salesforce Setup by searching for Paused and Failed Flow Interviews where a list view of both paused and failed flows can be accessed and each individual flow canvas can be accessed.

Option 3: Debugging Record-Triggered Flows with Reusable Test Cases

The final way of debugging flows is a newly released option from Salesforce currently only available for Record-Triggered flows, which allows users to create reusable test cases. This testing process will allow for predefined data to run through the flow and assess whether or not the runtime is successful. These test cases are similar to what a developer would create when writing Apex and help developers to test their record-triggered flows since they can be run on Create, Update, Delete, and before or after Save context. Note that test cases are currently not supported when you’re using a Delete context Record-Triggered flow.

The test cases for Record-Triggered flows can be created in two ways, both from within the flow canvas. The first is to debug the flow on the canvas, as per the steps mentioned in option 1. When running a debug case on a Record-Triggered flow after successful completion the user will be presented with a button to Convert to Test. This trigger will take the input values provided by the running user and save the debug case as a test case, which can then be used to run against future versions of the flow to ensure the runtime is still operating as expected. 

The second option is to create the Test Case manually. This is done by clicking the Test Cases button on Canvas. From here the user will need to fill out a three-step process to define their test case. The user will need to provide the following information:

• Set Test Details, Trigger, and Path
  The user defines the name of the test case and whether it will be fired on Create or Update of a record and in Immediate or Asynchronous context, depending on the complexity of the flow.
  
• Set Initial Triggering Record
  The user defines the record which will be used for the runtime of the flow. Here the user can select an existing record via a lookup, or provide specific record criteria if required for the test.
  
• Set Assertions
  The user sets the conditions and custom failure messages for each assertion they want to make as part of the test case. At run time, the test checks all of its assertions.
  
  • If all conditions for each assertion evaluate to be true, the assertion passes. If one condition for an assertion evaluates to be false, the assertion and test run fail.
  • If a failure occurs for an assertion during the test run, the custom failure message appears in the test run details.

---

These upcoming updates can be challenging to really understand for your org. Reach out to us and we can help your organization as you embark on your own journey with Salesforce Flows.