In celebration of #FlowFeb I describe the common problems I encountered when adopting Flow.  If you are starting out with Flow, I hope that you will find a few guiding principles below.

Next time I will go into more detail about how monitoring the progress of Flows helped me improve quality, and my productivity.

The Scenario

I’ve been writing Flows in earnest for about 6 months now, since the pilot/beta for Flow triggers came about and made it possible to run background processing.  In the beginning I was VERY lazy and didn’t bother to put any error handling into my Flows preferring to hope for the best when they ran.  In my defence let me say that the Flows were running in developer orgs or a very quiet corner of the Desynit live org, just to see what was possible.

Don’t Hope For The Best

My first piece of advice is to point out that hoping for the best and implementing business processes are not a healthy combination.  First of all, if a business process is supposed to happen and it doesn’t, somebody is going to be unhappy and start looking for you.  Second, if there is no alert or evidence that something went wrong it’s doubly bad (and they will realise eventually and come looking for you!).

My most immediate problem though was that my Flows weren’t running correctly first time, or for quite a few times during development and testing.  This was leaving me frustrated as I battled to develop my Flows.

Debug Log Monitoring

If I was going to make use of Flows seriously to solve real world problems for paying customers then I was going to have to up my efficiency and productivity, and that meant getting stuff working quicker.  I quickly found that it was possible to monitor Flows in near-real time by having the Developer Console open when I test ran the Flow.  Just as with debugging classic workflow and Apex, this was an easy way to capture the log and then read/search through it to find out what’s gone wrong.

I was able to use debug logs and the Developer Console to sus out the cause of Flow misbehaviour (“misbehaviour” is what I am choosing to call the results of my early slap-dash Flow programming) and these logs were helping me along the road of exploring the capability of Flow to model more complex business processes within our own live Salesforce org.

Handle All The Exceptions

Capturing logs worked well for development and testing, and taught me a lesson (as if it ever needed to be taught) that I needed to make sure I caught every exception which was raised in the Flow.  I ran into so many unexpected “unhandled exceptions” when first deploying my Flows.  The most common cause was that the Flow user did not have permission to update a field referenced in the Flow.

Ensure Correct Object Permissions

I banged my head against the wall many times, even with what I thought were the simplest of business processes, but Flows were just grinding to a halt because of field permissions.  That’s a whole other blog post, but take my advice and have a Permission Set for each of your Flows and make sure that the objects and fields in the Flow are set to read or write access as needed by the Flow.

Monitor Production

My next lesson came from trying to support my colleagues the first version of an invoice processing Flow which I had written.  There were problems with field permissions (I had not taken my own advice to have a Permission Set for the Flow), and also data scenarios which the Flow was not yet set up to handle.  In some cases I had exception handling which was reporting the fault to the user on their screen, in other cases the fault was not handled, and the Flow died in front of the user with a generic message.  For all my energy and enthusiasm about Flow and what is was going to do for us, they were not very impressed.

Get The Truth From The Source

I had my first Flow in production but it wasn’t working smoothly.  The feedback that I was getting from the users varied in quality and detail, and I could not always be on hand to look over their shoulder and get the information needed to correct the problem.

What I needed was the ability to capture not just the fault message from the Flow and any other information which would give me as much detail as possible so that I could understand how far the Flow was getting before it failed.  I needed to instrument my Flows..

Search #FlowFeb on Twitter for a selection of posts from other Flow fans.