Think Like a Developer When You Design Flows

Flows offer a lot of power to clicks-not-code administrators who want to automate processes using record lookup, update and create options offered with this easy-to-use feature.  Of course, Flows do require that administrators learn to think like developers a bit.  They must be able to outline the process the Flow should take, including decision points where the flow might go in one of multiple directions.  They must also think of ways to test and debug their Flows and to create Flows that can be reused or called in multiple ways.

You need to know how to look for bugs in your Flow.

Test Extremes

One rule of testing is to keep in mind the extremes and the improbable.  What happens when users enter data that is out of scope, or when a record that the Flow expected to exist (like a generic, default Account record) has incorrectly been deleted.  Make sure your Flow includes fail-safe procedures and uses error messages, which Flow makes available, to catch these situations.

Break Points and System.Debug

As you are developing your Flow, be liberal with Screens to display the values of variables along the different Flow paths.  One of the things I love most about Flows is the ability to create Screens that I do not tie into the Flow.  This enables me to create break points that halt the Flow before the error occurs and lets me display debug messages for myself between steps, providing the values of variables needed in subsequent steps.  When the Flow is ready to be activated for users, I can first disconnect all of the extra Screens and leave them in the Flow if there is a chance I will need to rework the Flow.

For example, between the record lookup step that assigns data to variables and the decision branch step where the Flow's path will be determined according to variable data, I will create a Screen to display the record ID and all of its variable data.  I won't bother to connect the Screen unless I find that the decision branch does not behave the way I expected.  I can even leave the Screen in place to use as in future versions of the Flow or to use later, when the data model defined with Salesforce objects and fields may have changed (the 'model' part of the Flow).  Otherwise, the Screen stays disconnected from the Flow.

Flow Triggers

For Flows to be used with Workflow rules, they are expected to operate without a user and so trigger-ready Flows cannot have Screens, which require a Flow user to click the 'Next' button to proceed.  This can complicate the debugging process, but don't be discouraged.  When you are first creating a complicated flow, you can still use Screens and simply call the Flow from a link or, to easily pass parameters, a Visualforce page.  See my earlier post for more information about calling a Flow from Visualforce.  Keep in mind that trigger-ready Flows cannot include Screens with error messages and so should be thoroughly tested outside of the workflow rule, to work out ways to avoid errors during the Flow execution.

Deleting the leftmost and rightmost columns
makes this Flow trigger-ready without Screens

Design Patterns

Converting a working Flow that has been created with Screens to one that is trigger-ready and without Screens is easy if you just employ a simple design pattern.  For my Flows, I keep the data and logic elements like decision branches and record manipulation, which you could call the 'controller' or core part of the Flow, in a vertical path down the center of my design.  For the Screens, which you could call the 'view' part of the Flow since that is the part Flow users can see, I push those elements out into columns to the far left and far right of my controller elements.  For example, a simple Flow would have two columns, the leftmost would be Screens only, the rightmost would be logic and record manipulation only.  A more complicated Flow might have Screens on both the rightmost and leftmost columns, like the one illustrated here.

By keeping Screens in their own columns away from the logic, they can be quickly selected within the Flow designer with a single motion and deleted from the design  when you are satisfied with the functionality so that the Flow can be used as part of a workflow without user intervention.

Flows can be executed by Visualforce pages, by other Flows, and by users; with Summer '14 Apex will be able to execute Flows as well.  They can be executed  from record detail pages using buttons, links and Actions; from Tabs, Force.com Site pages and from Global Actions.  Keeping the Flows small and function-specific will help make them reusable in these many scenarios so that you don't have to recreate the same functionality in multiple Flows.  For example, a Flow that operates from a workflow rule and also from an Action on a record detail page might have the 'controller' elements in one Flow that can be called by a Flow Trigger as well as by a Visualforce page that would provide some 'view' context for the user executing the record Action.

Even clicks-not-code administrators can be creative developers once they start designing for multiple uses and considering the debugging process and Model-View-Controller implementation patterns.  And as you become more comfortable thinking like a developer, you may eventually decide to learn more about the Debug Logs and Developer Console.  But with Flow, you might even decide you don't need those to create complex business solutions that work well for your users.

Why Should Every Admin Learn To Use Flow In Salesforce?

Flow, it is one of those under-appreciated features in Salesforce.  Many of us aren't even sure what to call it since it is known as Visual Flow, Visual Workflow, Flow, and sometimes the slight misnomer of Workflow.  I presented a session at Dreamforce '13 on Using Visual Flow for Cleaner Data, but the topic of Flow warrants even more attention than that!  And so, I offer part 1 of a three part series on using Flow in Salesforce.

Like Workflow rules, Flow can help your org conform to defined business processes.  Unlike Workflow, which lets you define rules and outcomes to operate fairly automatically and behind the scenes, Flow can interact with users in addition to conducting automated processes behind the scenes and so it is more flexible in its uses.  Some examples of use cases for Flow include:

• Stepping users through the data entry process with detailed instructions
• Providing a call-script for anyone who interacts with customers or donors
• Enforcing naming conventions by employing formulas in record names
• Ensuring data consistency with formulas for data validation and constants
• Simplifying the process of data entry for multiple objects such as parent and child related data
• Creating presentation and training materials

My Dreamforce presentation was created as a Flow and can be found online here: http://flow.snugsfbay.com

Flow diagram illustrates Lead and child record creation.

I created the Flow with several goals.  Foremost, I wanted to walk Salesforce administrators through the basic steps required to create a Flow.  When you step through the presentation, you will see videos, instructions and help related to designing and creating a Flow to gather data from a user and save that data to Salesforce. In my example, the Flow creates a new Lead record if a matching record is not found; it also allows for any number of Lead Notes to be added to a new or existing Lead.  All of this is illustrated in the presentation videos.

The presentation also includes information about incorporating decision branches into a Flow and using formulas for data consistency, for example the Lead Note child records are named though the use of a formula.  It offers instructions for making a Flow available to users along with the most basic code needed to create a Visualforce page to display the Flow as well.  The related videos demonstrate each of the steps involved in creating this Lead and Lead Note data entry Flow.

In creating this presentation, I also wanted to demonstrate the customizable user interface Flows offer.  Part 2 of my Flow blog posts will describe how to style your Flow and improve the user experience.