Anyone who deals with Flows on a regular basis dreads the Error Occurred During Flow (Previously the Unhandled Fault) message that we get from Salesforce. What we thought we built to perfection – isn’t. This isn’t very different from what we experience with an Apex trigger. Configuration changes can cause a previously well written Apex trigger to now not work as intended. Part of this might be that our Flow got used in a different way than we intended it to be used in. Now this becomes a real problem comes when we have an Autolaunched Flow and we hit an error. This stops our End Users from being able to save their record. So, how do we deal with that?
We use a Decision Element! Now, after any Record Lookup or Fast Lookup I always put in a Decision Element that will validate I found the variables I expected to find. If I didn’t put in these Decision elements, I could potentially have my End Users unable to save a record if a configuration change, process change, or simply lack of testing on my part happens. This means that while my Visual Flow would technically not work – I wouldn’t be causing records from being saved in the UI. Which in my opinion is the lesser of two evils!
While this process is not glamorous or fun, I consider it as my ‘test coverage’ for my Flow. I know that when I don’t include it there will be problems down the road! Murphy’s Law!
Lets show you how this would work!
We are going to be looking for a Queue’s Id based on a value matching the Queue’s Developer Name. If we have a match, we want to store the Queue’s Id and then update our related Case’s Owner as that Queue.
In the above image we are supposed to have found a Queue Id that we can use to update our Case. However, there is the situation that maybe we don’t have a match. Maybe someone changed the DeveloperName, or someone added another Queue ‘picklist value’ without adding the new Queue. Whatever the reasoning might be, we want to verify that we did indeed get a match!
The way we determine if we found a value is to see if ‘is null’ is FALSE. If it is FALSE, then we know there was a value returned!
Lets go to our next element, and in this case its updating the Case’s OwnerId field with our QueueId variable. Once again, if we attempted to do this update with a null value we’d be hitting a Flow Error and unable to save our record! But, we verified that we have a Queue Id if we hit this element, so we’re good to go!
So what does the final product look like? Take a look below!
If you notice, we’re not dragging a ‘no’ option from our Decision anywhere. Depending on your Flow, you might want to consider sending yourself (or your team) an email letting you know Who, When, and What happened. This will allow you to know if something is happening that shouldn’t happen. I’ll leave this up to you to determine how many emails you want to receive, but it can allow you to keep tabs on all your Flows!
RECAP: Decision elements allow you to validate that your Record Lookups and Fast Lookups actually found the data that you expected them to find. This means that we can make sure we have the correct data before proceeding on to any other elements that reference or use that variable with. Just because we don’t have to write test coverage for our Flow doesn’t mean we shouldn’t test to make sure our Flow is working as expected!
3 thoughts on “Decisions, your Flow’s Test Coverage”