Using Flows in Salesforce

Learn about the best practices and key considerations for Salesforce automation by delving into the world of flows.

Back when we launched this blog a few years ago,  workflow rules and Process Builders held the crown, reigning as the top picks for automating workflows. But as businesses evolved and demands grew more intricate, the cracks in Process Builders started to show, leading to their eventual retirement in 2023. Then, along came Flows–a dynamic way to tackle even the most complex processes with versatility and flexibility. Now, Flows are the only game in town, and any aspiring admin needs to learn how to play.

Whether  you need more convincing as to why you’d want to make the switch to Flows, or if you’re wondering how you can start building Flows efficiently and effectively, read on! We’ve got you covered.

Previously using Process Builder? Why Migrate to Flows?

  • Scalability: Flows can use custom metadata to reduce duplicate logic in processes and bulkify processes
  • Performance: Before-save Flows are 10x faster and after-save Flows 4x faster than process builders or workFlows
  • Manageability: Processes are slow to update and maintain
  • Flexibility: Flows can be triggered by more events and conditions than processes and perform many more actions
  • Integration: Flows can be integrated with other Salesforce tools like Einstein
  • Improved debugging: Flows provide more comprehensive debugging options than workFlow rules or processes, making updates and testing easier
  • Future-proof: Salesforce has deprecated the ability to create new process builders, and may deprecate the tool


Record-triggered Flows include many abilities that process builders do not, including their ability to: 

  • Create advanced queries to pull in information that isn’t located on the triggering record
  • Perform multiple database operations for the same business logic, so that records created or updated in the same Flow can be referenced later on
  • Choose whether to make fast updates to the triggering record (up to 10x faster than process builders) or to related records (up to 4x faster)
  • Delete records, and perform business logic when records are deleted
  • Make HTTP callouts to external systems


Flows also come in more flavours than process builders:

  • Screen Flows let users enter and interact with information dynamically
  • Scheduled Flows that run at a set time interval
  • Platform event-triggered Flows that listen for API events
  • SubFlows that can contain discrete business processes and can be reused in many other kinds of Flows

When to use a Flow vs. When NOT to use a Flow


  • You need to create/update/delete records, send a small volume of emails, or call invocable Apex code whenever specific conditions are met or on a schedule
  • You want to guide users through entering or updating information in a streamlined way, without the need to customize the appearance of that experience
  • You need to process a hundred or fewer records at a time
  • You want to take an action within Salesforce whenever an external API calls into the system

When NOT to...

  • Your Flow requirements require nested loops that cannot be eliminated by using the filter or sort collection actions
  • There is an existing Apex trigger framework on an object that can be easily modified
  • Your Flow requirements require DML elements inside a loop
  • You are working with very large data volumes
  • You need custom-built integrations with other systems that require more than a simple callout to an external service
  • There is other Salesforce functionality that can accomplish the same goals

What do I need to know when creating Flows?

A Few Considerations

Understand that when it comes to Flows, with great power comes great responsibility. Although Flows look simple and are intuitive to start building, they have the same power as code and can be just as dangerous to an organization. No one wants their end-of-quarter updates to grind to a halt because a Flow errored out!

Here are a few key things to watch out for when using Flows.

1. Be careful with null and unassigned values.

If you’ve ever received an error that says “variable has not been set or assigned,” it means that your Flow is attempting to use a value that doesn’t exist yet. For example, if you’re always trying to update the account related to a contact and your contact doesn’t have the Account field filled in, your Flow will fail. To prevent this, always use decision elements to ensure a record is found or a variable is populated before using it in the Flow.

2. Think about data volume.

Because a Flow can be triggered simultaneously on multiple records, you need to think carefully about how much data your Flow might try to process. For example, if every time an opportunity is won you are updating the status of contacts related to the opportunity’s account, you might be trying to update a lot of contacts! Salesforce has ways of automatically handling high data volumes (called bulkification), but as a safeguard, schedule the Flow with controls on batch size, or invoke the Flow using batch Apex.

3. Make sure your field types match up.

A common mistake with Flows is setting a screen component field type that does not match the field data type. Mismatched field types—for example, trying to put text into a number field—will inevitably cause failures in your Flow. This is another case where admins need to think like developers and make an effort to understand the data relationships within the object model.

4. Beware of loops.

Putting an update or a query in a loop will cause a “too many SOQL queries: 101” error if your data volume is too high. As a general rule, avoid ever putting an update or query in a loop, and instead use lists.

5. Think logically through all possibilities.

When it comes to Flows, a best practice is to always think very methodically through the logic of your steps. If you take the time to think through every possible route and decision your data may encounter in the Flow, you will catch and eliminate many of the possible errors outlined above. For every part of your Flow, ask yourself, “What will happen if X?” For example, what will happen if a user enters an unexpected value? What if a field is empty? What if a field is not required? And more.

In a nutshell: think like a developer, and you’ll avoid many common pitfalls.

Running into issues with your Flows? We’d love to hear from you!

Let's chat!