If you are an intermediate to advanced Salesforce Admin who hasn’t yet discovered Salesforce Cloud Flow, read on for a tutorial on this tool that extends Salesforce configuration without Apex code. We’ve included a brief history and overview of Cloud Flow and deconstructed an example that you can download from the AppExchange (for free!) and modify for your own Salesforce org.
In addition to the basics, we’ve provided lots of links for support and resources, and ideas of how you can use Cloud Flows to start building advanced functionality without code today. Let’s get started…
What is Cloud Flow?
Salesforce Cloud Flow allows the automation of a business process with a series of steps, or “wizard”, instigated by a user action. Cloud Flow steps and their connectors can be built with a visual interface that does not require Apex.
Salesforce acquired Informavores in 2009, and rebranded its Firefly tool as “Visual Process Manager’ in 2010. It has since also been called “Visual Workflow” and “Force.com Flow.” We’ll call it Cloud Flow.
Cloud Flow is not the same think as Workflow rules. They both have their use cases and work well together, as demonstrated in this video of Workflow and Cloud Flow use cases. See the chart in this article for more on the differences between Workflow and Cloud Flow.
Why Choose Cloud Flow?
Cloud Flow works well when you have a business process that:
i) Is consistent with a wizard-type series of screens to captures responses.
ii) Can’t be accomplished with a workflow rule (for example, it crosses objects besides parent to child).
iii) Is initiated by an action the user takes.
Cloud Flow can automate many such functions, and can be learned with the same skillset needed to create workflows, validation rules, and formulas. Here are some ways you could use Cloud Flow:
i) Capture data to open a Service Case.
ii) Provide a guided script for call centers.
iii) Capture data in “Prospect” custom object; when data meets threshold, create Opportunity.
Create a project with a Chatter Group and a series of assigned tasks.
To download some samples, grab the Visual Workflow Sample Pack from the AppExchange. Note that there are a few flows in this pack that require configuration to work in your Salesforce org, but it’s a good way to see examples of what Cloud Flow can do and practice updating them for your org!
The possibilities are endless. Here are some users who are really taking it to the next level; check out this Visual Workflow Hackathon.
NOTE: Cloud Flow is not a good substitute for forms where lots of fields need to be viewed all on one page, nor in cases where the Cloud Flow itself becomes more complicated than Apex would be to accomplish the same task.
How Do I Build a Saleforce Cloud Flow?
To build Cloud Flows, a User must have Force.com Flow User permission selected on his or her User record.
Let’s take a look at building a Cloud Flow. In the simplest sense, a Cloud Flow is a business process flowchart.
Some examples of what Cloud Flows can do:
i) Lookup, create, update, and delete records.
ii) Contain decisions, assignments, conditionals, and loops.
iii) Obtain user input with wizard interface.
iv) Be called from a button or link on an object.
v) Add a graphic to a variable using its URL (see the resources below).
vi) Create a Chatter post.
As you build out the steps, you can also capture data from the person running the flow, and make decisions. Let’s examine this Contact Form sample from the Visual Workflow Sample Pack:
In the Contact Form Sample we have:
i) A Contact Form screen to prompt for contact data
ii) A Record Lookup to check whether the contact exists based on the contact data
iii) A fault in case the criteria to move on in the flow isn’t met
iv) A decision as to whether the contact was found with the contact data
v) A Record Create to create the contact if not already in Salesforce
vi) A Contact End screen to thank the user for contacting the contact
Building Cloud Flow Elements
To build a flow, you drag the elements from the palette onto the canvas, double-clicking each element to edit its details. We’ll examine the Contact Form example.
The Contact Form Screen
The first element in the example is built by dragging a Screen element from the palette onto the canvas. When you first add an element, or double-click it, its details open. We’ve navigated to the Add a Field tab of this element:
The Contact Form in this element was built from dragging Textbox fields from the INPUTS section and naming them. When the flow is run, these fields will accept input from the user and the values will be stored in Screen Input fields.
Alternately, you can create variables and assign the screen input values to the variables.
The checkContact Record Lookup
The next element in the example was built by dragging a Record Lookup element from the palette onto the canvas. Click the diamond on an element and drag its connector to the next element in the flow to connect them.
In a Record Lookup, you specify the Salesforce object in which to look up the record – in the checkContact Record Lookup, Contact is selected. You also specify the criteria to match in a Record Lookup. In this case, it’s all three screen input fields entered in the preceding screen element: First Name, Last Name, and Email.
When the flow is run, Salesforce will search for a Contact record with values that match these three fields. Optionally, you can assign any field from that Contact record – such as its ID – to a variable you also define in the Record Lookup.
The Contact Found? Decision Element
The next element in the example was built by dragging a Decision element from the palette onto the canvas and connecting the checkContact element to it.
In a Decision element, you specify the outcomes for the decision, such that the flow branches based on which outcome’s conditions the data in the flow meets.
For this flow, an Outcome of “Yes, Contact Already exists” was added (by clicking Add Outcome in the left-hand column under EDITABLE OUTCOMES) and the condition for that outcome was that the value of the checkContact Record Lookup element equals true:
In this example, the DEFAULT OUTCOME was named “No, Create Contact.” The Default Outcome is what happens when no other outcome’s conditions are met in the decision element.
You could also build the “No, Create Contact” outcome as an editable outcome instead of making it the default outcome. To do so, you would select Add Outcome in the EDITABLE OUTCOMES section and set the condition for the outcome that the value of the checkContact Record Lookup element equals false:
If you built the checkContact = false as an editable outcome, the default outcome would then only be reached when checkContact is neither true nor false, which could happen if its value were null.
The situation where the conditions necessary to move to one of the next elements in a flow are not met is known as a Fault case and we’ll discuss these in a moment.
The Create Contact Record Create Element
The next element in the example was built by dragging a Record Create element from the palette onto the canvas, selecting Contact as the object for which to create a record, and assigning previously gathered values (in the Contact Form screen element) to the Description, Email, FirstName, and LastName fields for the Contact record you are creating.
The connector from the Contact Found? Decision element is dragged to the Create Contact Record Create element and the flow prompts for which condition you want the flow to move to the Create Contact element. You select the “No, Create Contact” condition because you only want to create a new contact when the data entered does not match an existing contact.
You can now assign the other condition (Yes, Contact Already exists) to flow to a different element. The flow will branch from the decision to one of these elements, based on which condition is met.
The ContactEnd Screen Element
The “Yes, Contact Already exists” condition from the Decision is mapped to another Screen element. This screen element contains a simple message, thanking the user for contacting the contact (using the contact’s first name).
Error Trapping (Creating Fault elements)
There’s one more element in the example, and that’s the Error Screen element. When we include a Fault selection for any element, the Cloud Flow will choose the Fault if it doesn’t meet the criteria to go to any other element in the flow.
In this example, when the Record Lookup tries to find the Contact in Salesforce, if for some reason the flow doesn’t meet the criteria to move to the Contact Found? decision, it will flow instead to this Fault element, which displays the flow’s fault message (the reason the flow could not move on).
If a Cloud Flow can’t move to the next element, and there is no Fault selection, the flow will crash, and throw an Apex error (presented in the fault message). Sometimes the fault message will be sent to your email, but not always, especially if you have already received the same error from that flow on the same day. So it is a good idea to include the fault message in a screen element as shown in the example.
Activating and Running Cloud Flows
Once a Cloud Flow is built, if you want to call it from a button or link in Salesforce, the flow must be activated. You can then use its URL from the Cloud Flow detail page to build a button or link.
On the Cloud Flow detail page:
i) Click Open beside a particular flow version to edit it or review it.
ii) You can see which, if any, version is activated in the Flow Versions section of the Action column.
iii) You can only edit an inactive version.
Errors and Troubleshooting
You will get an email from FlowApplication – sometimes – when a user runs a Cloud Flow that has an unhandled exception or “fault.” These messages look more cryptic than they are. When you receive an unhandled fault email for your Cloud Flow, look for the caused by element, and the actual error.
Below, the caused by element is the Update element called “Create_Chatter_Group.” The upsert failed because the required field CollaborationType was not passed by the upsert (and is required).
Sometimes the errors are less straight-forward. In the example below, it’s not that there is something wrong with the SObject Territory__c, but rather that the user running it did not have access to View All data for that object.
However, you can still see which element caused the error and what Salesforce perceived the error was.These errors illustrate why it’s useful to handle faults by creating fault elements as described in the Error Trapping section. There are many reasons the data in a flow may not meet the criteria to move on to the next step. You can also use “Show Me” screens in a fault element to report back the values of variables, the Fault Message, or indicate what step you were on when the error occurred.
Here’s are some more excellent tips for troubleshooting Cloud Flow issues.
To build Cloud Flows:
i) Drag and drop each element onto the canvas.
ii) Set the start element. Each flow must have a specific starting element.
iii) Click the diamond at the bottom of an element and drag to the next element to create the order of the flow.
iv) Double-click an element to edit its details.
v) You can run a flow from the Flow Designer or use its URL to create a link or button to run it (see Activating and Running Cloud Flows).
vi) Activate the flow in order to run it from a Salesforce record outside of the Flow Designer.
Additional Cloud Flow Resources
There are many resources available to help you learn more about Cloud Flow. The Cloud Flow Designer Overview guided tour is available when you first create or open a Cloud Flow.
Here are some other resources to get you started.
- https://www.youtube.com/watch?v=jfbUjJg1t-0 (Dreamforce)
- https://www.youtube.com/watch?v=0A1fLDlC5bY (the Salesforce Non-Profit Org)
This post is intended to get you thinking about Cloud Flow and show you some basics. There is much to learn about Cloud Flows and as usual with Salesforce, the best way to learn is by doing.
If you have a Cloud Flow you are particularly proud of, write about it in the comments section below!