Debugging flows
Tips and tricks for debuging flows
Use an initial assignment element to set your variables. Makes testing flows much easier. H/T : salesforceyoda
Insert screen elements for breakpoints, but just include text in them for starters, ie breakpoint1. You don’t want the screen element itself to trigger an error, which can happen if you include formulas, etc. Once you can get through the breakpoint, then add variables to display detailed info.
If your flow is autolaunched, you can debug using a send-email element instead of a screen element, but if you are building a new flow its easier to debug using screen elements and you can switch to autolaunched later.
You can display sObject variables and sObject collections in screens. The collection will display a list of IDs if populated, or a list of commas if the sObjects have not been inserted yet, or nothing if it is null.
If you flow has a wait element, you must customize the flow interview label. This will give you insight into what is happening directly on the ‘waiting interviews’ page
Always add fault connectors where possible. These allow you to catch and handle many (but not all) types of faults! Handling faults simply means that you can decide how to surface the error to the user, instead of the user seeing the awful ‘unhandled fault’ screen or the ‘the record did not save because it failed to trigger a flow’ message.
Most faults are preventable with proper design. When a fault happens, handled or unhandled, figure out why and decide what, if anything, you need to do about it. Dont just ignore them!
All faults trigger flow error emails to the person who created the flow.. These have very useful info, but can be tricky to debug. See this post for help in understanding the flow error email.
Things to look for when a flow blows up
a. figure out what blew up and where it blew up
See the post above on how to understand the flow error email to understand what blew up, and where it blew up.
If the fault is handled, you know where the error happened.
One thing to look for is make sure you are storing the right fields from a fast lookup. If you reference a field that you don’t store, you get an unhandled fault, with the error *“The flow failed to access the value for {fieldName} because it hasn’t been set or assigned.” This cant be handled because there is no fault connector path on a screen element. It will always blow up on the user.
If you use a cross object field reference, Flows and process builder do not gracefully handle blank lookup fields. So if you reference Contact.Account.(somefield) and Account is blank - boom! You must first evaluate that the lookup is not blank. The order of the criteria matters. Always test this scenario!
DML Errors. Flows are subject to standard governor limits and have some of their own limits. For example, creating more than 150 records in a loop can cause the following limit : Too many DML statements: 151. This error can be handled w/ a fault connector. Note that screen or wait elements in flows start a new transaction with a new set of limits, so this can be a good tool for handling complex scenarios.
If flow works in testing but not when launched via button/process
check if variables set to private
variables in url are case sensitive