Do you write Flows? If so, congratulations, you’re a developer. No no, you are. You’re developing software, just with a declarative interface, so yes, you’re a developer. And what does every developer have to do, even though they hate it?

Test. Test. Test.

Once you’re a developer, you’re not exempt any more! Welcome to the development world. Yes, we hate testing. We like to think our Flow is just going to work the first time, but in all of the 30+ flows I have written in my time, I can only say that I am just lucky enough to have gotten away with it once. Seriously, that’s like a 3% chance.

Even then, I played it safe, and verified that it was going to work right by testing it first. You will save yourself SO much time and frustration by testing before deploying.

Flow is a unique beast, though, and there’s not a lot of documentation out there on how to test your stuff. By and large, we’re left wondering just what we should do to actually test. There’s some obvious things, but then the only truly obvious route is to actually deploy in order to test, and that’s not always a good option.

So without any further ado, here are some of the methods and guidelines I have come up with for testing my Flows.

1. Sandbox Sandbox Sandbox

I know sandboxes seem like a waste. I know the concept is alien to some of us. But really, do it. DO IT. This is especially important for Flow Triggers, which, I can attest to personally, can cause stupendous failures.

When a Visual Flow crashes, it only affects the person trying to run the flow, and usually just throws an error. When a Flow Trigger crashes, that crash can affect ANYONE who is trying to do their work. Even if you have “Administrators run the latest flow version” turned on, you can still have problems if you haven’t activated any versions. So trust me when I say, Sandboxes are more important than ever before for Flow.

2. Always Fault

There’s nothing that your users hate more than a cryptic error. Seeing

“An unhandled fault has occurred in this flow. An unhandled fault has occurred while processing the flow. Please contact your system administrator for more information.“

is the surest way to frustrate and confuse, not to mention driving your users AWAY from using your blood-sweat-and-tears Flow. Nobody wants to use a tool they don’t understand, so quite simply, they won’t.

So how do we avoid this? We add Faults.

Every Create, Update, Lookup, or Delete.

Any Record or Fast Element can have a Fault element attached to it, and your best practice is to ensure that every Record or Fast Element has a Fault element attached to it. A Fault element can be made by creating any element and drawing an arrow to it from your Record or Fast Element AFTER they already have an arrow pointing to another element. If the Flow errors on that source element, it will then perform whatever is in your Fault, rather than showing that “unhandled fault”. That’s what unhandled means; it means that you haven’t defined what should happen when a fault happens.

A fault can contain a message to the user, it can create records, it can even send an email if you use the Email Plugin. Anything Flow can do, you can make happen from a Fault, so this is invaluable not only to your users, but also to your debugging and testing. Having a screen that tells you what your variables’ values are AT the point of failure is essential.

Another quick tip: if you want your fault to do things AND present a screen (I almost always have mine send an email and then show a customized error in a screen), do the email or other things first, THEN do your screen. If a user gets an error message screen, they are a lot more likely to exit the screen instead of clicking the Next or Finish button, and if they don’t click that button, it WON’T fire your email or other actions.

3. Gotta Test ‘Em All

This is another drudgery chore, but as admins I cannot stress enough that you have to personally try out your functionality. Don’t just try your flow while logged in as you; try it while logged in as the actual users who will use it. Try each choice option you present in your screens, or at least a sample of them, if there are too many to test. Make sure you run your Flow through every possible decision path, to be sure each decision path actually works.

Also, try your flow while logged in as the actual users who will use it. What, I already said that? Well, good, it needs to be said again. It’s so easy to forget to do, because you have to do it in a sandbox in order to do it safely, but it’s one of the most important things you can possibly do in your testing.

So How Do I Test Exactly?

The Temporary Assign Element Method

The Run button is a great option in the Flow Designer, but unfortunately it’s fairly useless without some setup. Almost every flow needs some data passed to it, and that Run button cannot pass any of that data. So how do we make it useful again?

Create an Assign element BEFORE the start of your Flow, and in it, assign some sample data to the variables that would usually have been set. Draw its arrow going to the start of your Flow, and then make the Assign element the actual starting element.

You can now use the Run button with impunity! This makes testing a lot faster when you don’t have to click around to get to your Flow, and it has the additional bonus of being able to test your Flow (at least, the testing that you do while logged in as you) without making it live for everyone. It’s a great way to do quick proof-of-concept testing as well.

Please keep in mind this doesn’t work on any flow with sObject variables or collections at this time.

The Screen Debug Method

This ties in directly with bullet point 2 above. If, in your testing, you hit an error or bug or other unexpected result, being able to insert a temporary Screen that just repeats what the variables or Screen Choice values are at any given point can be the key to unlocking the mystery behind your dysfunctional flow. There is no reason this cannot be done at any time; you can insert this into the middle of your flow’s track without having to use a FAULT path, so you’re seeing things as they happen, even before the error comes down.

Of course, because this method uses Screens, it is incompatible with Flow Trigger flows. Bummer.

[Edit: Removed the Flow Debug object method. Turns out this has some pretty glaring issues with most faulting in Salesforce. Thus reiterates my overall point about being extremely thorough in your testing of, well, anything.]