An Introduction to Salesforce Flow

No Admin should ever have to code! That was my first impression when I first heard about Salesforce Flow (Also called – Visual Flows, Visual Workflows). Since then in almost every requirement where traditionally I would use Apex, Flows did the trick. Need to mass create/update/delete records based on the information that you want to get from totally unrelated records? Flows is the answer.  Want to streamline your opportunity creation process without the need to code? Yes, you guessed it right, Flows. The use cases for Flows are endless, but for this post, I will focus on the following topics:

– What are Flows?

– What features are included?

– How Flows can be run.

What is Salesforce Flow?

Flow is a powerful business automation tool that can manipulate data in Salesforce in a variety of ways. Such application can be created right from the org’s setup with just drag-drop/point-click. The ease of creating flows makes it the number one go-to tool when it comes to complex business requirements. It is not only easy to create, but also it does not require any coding. Beware! That does not mean you don’t need to know the Salesforce platform’s object relationships and overall how Salesforce runs. You have got to have (at least) mid-level understanding of SFDC and its features in order properly use flows.

First, we are going to show how a flow is created and how it flows (it is a flow after all, isn’t it?). Flows can be created from Setup, enter Flows in the Quick Find box, then select Flows, and then click New Flow. We will use one of my not-so-complex flows as an example:

This flow is running from a custom button on the case page layout. In a nutshell, it allows the user to dynamically choose account record and looks up (in the background) the contact object if contact record with input email exists. If contact record exists it goes ahead and updates the case with correct contact records, otherwise, it creates a contact and relates it to the case.

There are 3 main “building blocks” of the flow, as seen in the screenshot:

1. Elements represent actions that are executed in the flow;

2. Connectors define which path the flow takes;

3. Resources are the values that can be referenced anywhere in the flow.

We will talk about all these building blocks in more detail later in this post.

What Features are included?

On the left side of the Flow Designer, we get 3 tabs: palette; resources; explorer.

Palette

Palette gives access to a number of elements that can be used to build the logic.  The main elements are as follows:

User Interface element Screen – Users can interact with the Flow only through this element. It lets the flow -collect information from the User and pass it to other elements for processing

Logic Elements:

– Decision – helps to determine the direction of the flow

– Assignment – can set, change, add values of/to variables

– Loop – iterates through the values of a collection variable

– Wait – it becomes handy when the flow needs to wait for an event to occur and define exactly how the flow should behave in such event.

DML operations:

– Record Create/Update/Lookup/Delete –the names speak for themselves. We can look for and Delete records right in here (codeless Heaven for Admins).

– Fast Create/Update/Lookup/Delete – these are doing almost the same things as elements above but by using only sObject variables. Using Fast elements helps to bulkify the transaction. For example, if there are 50 records that need to be updated, then it is better to have Fast Update element to update 50 records at once, instead of having Record Update run 50 times, which increases API calls to the database.  

– Then we have Flow elements which list all the flows that we have in our org. This helps to nest flows within each other.

Email Alerts – you know this one ? all email alerts that are being used in workflow rules and process builder in your org are included in this section

Quick Actions – yes, every single quick action that has been created in your org is available within the flows

– At the end we have Apex and Static Actions elements, in this part of the story we can work with developers to use Flows and Apex coding together to build some very powerful applications.

Resources

Resources – these are used to collect, store, and pass the data within or outside of the application. Based on the demand we can choose one of the resources below:

Variables – changeable resources that can be updated within the flow, or from outside (passing value thru URL, Visualforce page). Used for passing values throughout the flow;

Collection variables – does the same trick as variables, except as many values within the same data type can be stored in this resource;

sObject variables – changeable resources where we can store a record of a specific object type, when stored in sObject variable all the fields of that record can be accessed through the same variable;

sObject collection variables – stores multiple records of a specified object type, this resource can be used to Fast Delete, Fast Update, and Fast Create records;

Stage (Beta) – newly added (Spring 18’) resource that used to indicate the Stage of the process/flow where the User at;

Constant – fixed value, can be used throughout flow;

Formula – dynamically creates a value with the help of other resources in the flow;

Text template – Formatted text, the best part of this, html code can be used here (we will talk about it in the future);

Choice – individual choice option;

Dynamic-record choice – a very powerful resource. Shows a filtered list of Salesforce records to the user, and stores one record that the user chooses;

Picklist choice – Salesforce picklist or multi-select picklist can be stored here for use in the flow;

Note: Most of these resources are familiar to power-users but I would like to encourage you to research and learn more about sObject variables and dynamic-record choice resources, those come in handy in some pretty complex cases.

Explorer

The Explorer is simply a library that includes all the resources and elements that are being used in the flow.

How are Flows run?

The awesomeness of the Flow does not end there, another perk is it can be run from almost everywhere. However, to determine where to run them we need to know the flow types, there 2 main types:

Screen Flows – as the name suggests includes screen element to gather information from a user, this means that the flow type requires a user interaction. This type of flow can be accessed in a number of places: custom button; custom link; direct URL, Visualforce Page, or Salesforce app action. Note: Wait element is not available here.

Autolaunched – run in the background with no need of user interaction. It still can run everywhere that Screen Flows run, in addition, we can run it from process builder and Apex. The official Visual Workflow Guide says Workflow action is in pilot so I guess it will be available for public use in the future, and then we will be able to run autolaunched flows even from workflow rules. Note: Screen element is not available here.

Conclusion

To summarize, Flows include a lot of powerful features which would be useful in every single org. This post is the first in a series, with the purpose of familiarizing you with Flows and to show what their capabilities are. In upcoming posts, we will be talking about flows’ best practices and we will be sharing real-life projects.

Subscribe To The Monthly Newsletter

No Spam. No Rubbish. Just great content from the Salesforce Industry.

You have Successfully Subscribed!

9 thoughts on “An Introduction to Salesforce Flow

  1. Thanks for this post! Funny fact: I‘ve set up my very first Flow today before reading this! Looking forward for best-practices!

  2. I currently am working on a custom app and I have a lot of flows with loops in them. I have a few that have record creates in the loop and I have heard that may cause issues. Do you know if there is anything that may be a problem with creating records in a loop? It could be up to 500 at once.

    1. Rob,

      As Michael mentioned in below comment, you may hit SOQL limits. The best practice is “bulkification”. In Another word, you use sObject collection variable with the help of Assignment and Loop elements. Basically, you store every record in the collection and when the loop ends you create/update records with fast create/update element. It will help to decrease your SOQL calls to the database by a lot (depending on the record count) because it is running as one batch instead of number of batches. So, in example of 500 records, if you have update/create element within the loop you will have 500 separate batches performed rather than 1 batch if you use fast update/create outside of the loop.
      For more on bulkification please refer to official guide:
      https://help.salesforce.com/articleView?id=vpm_admin_bulkification.htm&type=5
      For more on Flow limits:
      https://help.salesforce.com/articleView?id=vpm_admin_flow_limits.htm&type=5

      Since Flow limitation and bulkification are 2 major interests, I will write my next blog post on this.

      Kind regards,

      Elgun

  3. This is very helpful – especially the translations/definitions of each of the terms! Thank you very much. I needed this.

  4. Great article. There’s a Flow “gotcha”- be aware of Flow limits, the main one being if you edit records in bulk, and the act of editing fires a flow, then you may hit the SOQL query limits resulting in horrible error messages as Salesforce strings it all together as one big flow. if using Flows try and limit use to occasions where you know they will be fired individually

  5. Thanks a lot for your kind words!

    Rob,

    As Michael mentioned you may hit SOQL limits. The best practice is “bulkification”. In Another word, you use sObject collection variable with the help of Assignment and Loop elements. Basically, you store every record in the collection and when the loop ends you create/update records with fast create/update element. It will help to decrease your SOQL calls to the database by a lot (depending on the record count) because it is running as one batch instead of number of batches. So, in example of 500 records, if you have update/create element within the loop you will have 500 separate batches performed rather than 1 batch if you use fast update/create outside of the loop.
    For more on bulkification please refer to official guide:
    https://help.salesforce.com/articleView?id=vpm_admin_bulkification.htm&type=5
    For more on Flow limits:
    https://help.salesforce.com/articleView?id=vpm_admin_flow_limits.htm&type=5

    Since Flow limitation and bulkification are 2 major interests, I will write my next blog post on this.

    Kind regards,

    Elgun

Add Comment