Optimizing and Troubleshooting Flows

So far, we have learned the building blocks of Flow Builder, understood the intricacies of various flow types, and observed the power of Salesforce flows. We gained insight into how to transform and automate business needs and processes and create an amazing user experience. Now, it is time to ensure that your flows are optimized, working as intended with minimal or no issues, and meeting your business needs.

In this chapter, we will explore and learn how to use the Flow Builder debug window to optimize and troubleshoot flows. Anything developed either declaratively or using code will run into some kind of bug, and you need a tool to be able to understand the error message and what it means. We will discuss a few scenarios to effectively debug and make sense of the flow for the users.

In this chapter, we will cover the following sections:

• Learning about the Flow debug window
• Understanding flow errors
• Practical scenario –...

Learning about the flow debug window

Debugging from Flow Builder can be done with simple clicks. We do not need to create debug logs using trace flags and then go through debug log details.

What are debug logs?

A debug log records database operations and system processes such as validations, assignment rules, and so on, and any errors while executing a transaction. The system generates a debug log for a user to execute a transaction. You can specify a trace flag with start and expiration dates that contain the transaction’s start time. Debugging logs gives greater details, and you need to have a good level of technical skills to be able to interpret these logs.

Flow debug is not just to be used when we run into issues. This is an extremely helpful tool for us to test chunks of functionality and make sure it works end to end as desired. The debug window captures details that let us see how our flow flows. This provides step-by-step results on how well the flow has been...

Understanding flow errors

So far, we have seen a happy path and understood how our flow behaves. But even with due diligence and thorough planning and testing, there will always be some scenarios and edge cases that are bound to fail and cause nightmares for your team.

If we do not plan and design our flow, users will run into exceptions with no information on why they failed or some cryptic message that no one can understand. What do they do now? Get frustrated?

To remediate this problem, we need to plan for these exceptions. Issues will happen, and if we are prepared to handle them promptly and fix the root cause, we will create a better user experience.

We can enable this in more than one way:

• By displaying a custom-specific error message and informing the users exactly what caused the issue, they can fix the issue and retry. For example, we can notify the users that certain fields are not accurately populated, or a specific value is invalid.
• For an auto-triggered...

Practical scenario – failed flow example

I purposely introduced a few errors in the flow so that we could review and get a good understanding.

Scenario: When the lead is updated to status = Working-Contacted and annual revenue is greater than $1 million, create a contact. We need to add a required field called security on contact via flow, and it should be 10 characters. We will hardcode this value in the flow for testing different variants.

Create a record-triggered flow with two conditions: status = Working-Contact and annual revenue greater than 1 million.

This triggered flow runs immediately when the preceding conditions are met and a lead is updated. See Figure 8.8:

Figure 8.8 – Record-triggered flow: Lead to Contact flow

Start the interview flow by clicking on Debug. This opens the Debug flow window; see Figure 8.9. The flow runs immediately and in rollback mode. This means that the flow debug process ensures that when the...

Flow tips

At a high level, as an administrator, you need to consider the following when designing flows:

• Flows launched by another flow via a sub-flow element count as one flow interview.
• Flows from managed packages cannot be opened.
• Session timeouts will impact your flows; if the user session expires, flows in progress are interrupted and cannot be resumed.
• Publicly accessible screen input fields should not be mapped to rich text fields to prevent malicious URLs. Remove all HTML tags.
• When designing flows, consider which fields are accessible to your users. Some users may not have access to certain fields, and other users may have access to those fields.
• Flows fail when a filter condition from a Get/Update record element references a null value. Use a decision element to check if the value is null before referencing it in the filter condition.
• Salesforce does not save flow changes automatically. You must explicitly save them often so as not to lose...

Summary

In this chapter, you learned how to use the flow debug feature. You understood a flow interview from start to finish for a good use case, encountering no faults at any steps. This is the first step you need to take to make sure at least one scenario works flawlessly. We learned about various ways of catching flow errors and how we can utilize fault connectors to elements on the screen or send notification emails to your admins. We reviewed what to look for and troubleshooting flows, as well as customized error messages so that your users are informed. We concluded with a practical scenario introducing errors into our flow and seeing the executing steps in the debug details.

In the next chapter, we will explore how we can streamline and enable complex business processes using flow orchestration.

Questions

1. What is a flow interview?
2. What is a fault connector, and how do you add one to your flow elements?
3. What is the best way to find errors in your flow?

Further reading

• Flow Limits and Considerations: https://help.salesforce.com/s/articleView?id=sf.flow_considerations.htm&type=5
• Flow Bulkification in Transactions: https://help.salesforce.com/s/articleView?id=sf.flow_concepts_bulkification.htm&type=5
• Customize What Happens When a Flow Fails: https://help.salesforce.com/s/articleView?id=sf.flow_build_logic_fault.htm&type=5
• Other Examples of Error Handling in Flows: https://help.salesforce.com/s/articleView?language=en_US&id=sf.flow_build_logic_fault_examples.htm&type=5