Introduction to Salesforce Flow

Share this article...

Salesforce Flow empowers you to build complex business solutions using clicks, not code. Flow Builder is the most powerful tool that a Salesforce Admin has at their disposal, giving you similar powers that Salesforce developers have. If you need to perform mass updates across multiple unrelated records, or complex logic into opportunity conversion, these are common examples for when you should use Flow.

The use cases for Flow are endless, and its capabilities are growing with every Salesforce release. Formerly Visual Flow, Salesforce Flow has gone through significant upgrades to give us the Flow Builder interface, after being completely rebuilt from the ground up!

Today, I’ll take you through Salesforce Flow basics, and answer the following questions: What are Flows? What are Flow’s features? How can Flows be called? And finally, can Flows become the ‘one tool to rule them all’?

What are Salesforce Flows?

Flows allow you to build complex business automation using clicks instead of code. As an admin, Flows are going to be your best friend because you will be able to handle the majority of complex business requirements without the help of a Salesforce developer!

The benefit of Salesforce Flow is that they are easy to maintain because anyone (assuming they know Flows) should be able to follow along with what you built.

Flows are accessible through the Setup menu. Simply enter ‘Flows’ into the Quick Find box, and create a new Flow to get started.

There are 3 main “building blocks” of any Flow:

1. Elements are the individual building blocks of the Flow. These perform logical actions such as assignments, decisions, or loops. There are also data elements that will query the database or commit record changes.

2. Connectors determine which element leads to which. Winter ‘21 enables Auto-Layout, and connects the Elements together automatically.

3. Resources are the individual variables of data that are to be used in a Flow – these can be strings of text, numbers, records, formulae, or collections.

You can see these in action on the Flow Canvas below. This example Flow below is a declarative replacement for a ‘before’ trigger. In the ‘Start’ element at the top you can see that the trigger is when a record is created or edited, and it should run before the record is saved.

What Are the Basic Flow Features?

On the left-hand side of your Flow Canvas, you’ll see the Toolbox. Depending on the type of Flow that you’re working on (whether it’s a Screen Flow, Auto-Launched Flow, etc.) you’ll see a different set of tools.

Manager Tab

In the screenshot below, you can see the Manager tab that contains the existing elements and resources of the Flow (this is from an Auto-Launched Flow):

This is where your Resources are kept. Some examples of Resources are Variables, Collections, Constants, Formulae, or Choices.

  • Variables are where you can store data to use in the Flow. These can be Text, Number, Record, Dates, Currency, Boolean, or Picklists just to name a few.
  • Collections are a group, or ‘list’, of Variables stored together. Collections allow you to process multiple records at once, or ‘bulkify’ your Flows.
  • Constants are values you set once and never change. They are useful when you want to refer to a single value multiple times through your Flow – if you ever need to change that value, you just need to change it once and it is reflected throughout the Flow.
  • Formulae display a dynamic value depending on other values within your Flow. If you need to calculate a future date based on when the Flow was run, a Formula will be helpful. If you need to calculate and set a currency based on an interest rate, a Formula can be used.
  • Choices are used within Screen Elements to display an option to the user.

Elements Tab – Interaction, Logic, Data Elements

Next, you have the Elements tab. This is where you can create new Resources and Elements in the Flow. In the screenshot below, you’ll see a ‘Screen’ element (because I took the screenshot in a Screen Flow, which will not appear in a Flow type that doesn’t support Screens, such as an Autolaunched Flow). There are a number of different elements that will dynamically show up depending on the type of Flow you’re working with.

 

 

Interaction elements include Screen, Action, or Subflow.

  • A Screen element, only available in a Screen Flow, allows you to present a screen to the user. This screen can display information from the data your Flow is working on, or it can be used to collect information from the user.
  • An Action element allows you to pass data through to a pre-existing standard or custom action such as Send Email, a Quick Create, or a custom Apex action.
  • A Subflow element allows you to call another Flow within your current Flow – this means that if you have another complex Flow set up, you don’t need to replicate the logic in your new Flow. This also makes maintenance easier as you only need to update your logic once if you design your Flows well enough!

Logic elements include Decisions, Assignments, and Loops.

  • Decisions allow you to split your Flow depending on the data that’s being sent through it.
  • Assignments allow you to give a value to a variable.
  • Loops allow you to handle multiple variables at once using collections.

Data elements include Create, Update, Get, or Delete records.

Essentially, any time you want to edit a record in the Salesforce database, you’ll need to use one of these Data elements. These will also dynamically display depending on the type of Flow you’re running. If you’re running a ‘before triggered’ Flow, you’ll only be able to use ‘Get’, for example.

How Do You Call a Flow in Salesforce?

To ‘call’ a Flow means that something happens in order to kickstart the Flow process. This could be a Salesforce record change, from another process in Apex/Process Builder, or automated on a recurring schedule.

When you create a new Flow, you’re prompted to select the type of Flow you wish to create.

  • A Screen Flow is called through a button or action, or displayed in a Lightning Page or the Utility Bar, and appears as a screen to the user to interact with. This cannot be automatically called.
  • A Schedule-Triggered Flow runs automatically to a recurring schedule. This is handy for tasks that need to be performed daily on a set of records, or to handle jobs that run frequently.
  • Autolaunched Flows are called through Apex, Process Builder, or another Flow. They can be used to perform actions automatically behind the scenes.
  • Record-Triggered Flows begin when a record is created or updated, very similar to Process Builder (more on this later).
  • Platform Event-Triggered Flows are called when a platform event is received, similar to an Autolaunched Flow.

Can Flows Be the ‘One Tool to Rule Them All’?

This is something that I keep thinking each time I read the Salesforce release notes. Flows are evolving at an incredible rate, and with Winter ‘21, they’re doing things that have been previously reserved for Apex – they can be scheduled, they can be triggered on record updates, they can be called by platform events. They can be visible or invisible to the user.

You can build incredibly complex logic into them, and reuse that logic across multiple Flows without having to rebuild them. They can do most things that Process Builder, Workflow Rules, and Approval Processes can do plus more.

Personally, I don’t think we’re far off from a world where Flows are the only tool that admins use, which would make it easier for any admin to jump in and see all of the declarative automation logic in one tool, rather than having to learn multiple tools and sieve through them looking for why a value on your Opportunities are getting overwritten all the time!

To achieve this, Salesforce will need to evolve Flow further to include more of the features that other automation tools have (I’m looking at you, time-based actions). We’ll also need to learn how to properly design good Flows that recycle logic, are designed to bulkify processes, and that have clear and descriptive documentation around them rather than building willy-nilly and keeping information in our heads.

Something else you’ll notice if you look closely at all my screenshots above…they all have a small opaque circle in them. That’s the cursor on iPadOS! This entire article was done on my 2018 iPad Pro, including the sample Flows I built. Since replacing the Flash-based Flow Designer with the modern Flow Builder, I’ve been able to create and edit Flows on the go using my iPad. Just another reason Flows are so powerful – they’re now mobile (technically speaking).

Summary

Today, I have taken you through the basics of Salesforce Flows to answer what Flows are, the features, and how Flows can be called. Finally, I shared my thought on why Flows could become the ‘one tool to rule them all’.

As you can see, Salesforce Flow is a powerful tool that empowers admins to build complex business solutions, possibly the most powerful tool that a Salesforce Admin has at their disposal! The use cases for Flow are endless, and its capabilities are growing with every Salesforce release.

I can’t stress enough just how much learning Flow Designer (back in the day) changed how I viewed Salesforce. I learnt that I could build a functional business system without having to learn Apex, and I could quickly assist department heads to implement custom logic in a few hours. I would recommend learning Flows to absolutely any admin who uses Salesforce (and I do!). That said, with great power comes great responsibility! There are a number of best practices that need to be followed to ensure your Flows are future proof and scalable (something we’ll go through in another post!)

12 thoughts on “Introduction to Salesforce Flow

  1. Avatar

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

  2. Avatar

    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. Avatar

      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. Avatar

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

  4. Avatar

    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. Avatar

    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

    1. Avatar

      Hey Chetan, if you mean making it invisible to a certain group (profiles?) of people, then you can create different screen elements and give access to those screens based on the group of the User through the decision element.

  6. Avatar

    Rosalina M Livingston

    Reply

    I am starting my journey to understand the theory of Flow and then use cases, this was a great introduction. Please keep up the awesome blogs (I’ve been a subscriber for a few years now and have been working with the platform for over ten) when I read you blogs you really deliver in a logical and easier to read mode then Salesforce H&T.

Leave a Reply