There is no doubt you have heard of Salesforce Flows – they are soon to be the one-stop shop when it comes to declarative automation (using clicks, not code) on Salesforce’s platform. Salesforce Flows can be a powerful tool for any Salesforce org. They allow you to automate business processes easily without having to write code.

In this article, we will talk about a number of best practices that you need to know while working with Salesforce Flows. You will also learn about the different types of Flows that you can create (Record-Triggered, Screen Flows, etc), how to debug Flows, and finally some scenarios where you should not be using Salesforce Flows.

What is a Salesforce Flow

While Salesforce Flow has been around for a number of years, it is now elevated within the ranks of Salesforce automation tools as the only declarative automation tool that Salesforce Admins and Developers should use. For a while, it has existed alongside two other tools: Workflow Rules and Process Builder. Salesforce has begun the migration of these two tools to Salesforce Flow, primarily to avoid confusion as to which tool to use and reduce complexity by having all automations run through a single tool.

Salesforce Flow supports complex processing concepts such as collections, looping through collections, and supports the ability to run specific Flows either before or after a Transaction (and it supports the ability to run asynchronous Flows). Salesforce Flow also supports the ability to create user-facing screens, and allows Lightning Components to be used to enhance these interfaces.

Types of Salesforce Flows

There are five different types of Flows that you can create, each with its own purpose and special functionality.

Screen Flows

These Flows require user input. You can create Screen elements and configure interfaces for your users.

Schedule-Triggered Flows

These Salesforce Flows run on a specified schedule and perform automated actions behind the scenes.

Record-Triggered Flows

These Flows behave similarly to Apex Triggers in that they are triggered when a record is created, edited, or deleted. They also perform automated actions behind the scenes.

Platform Event-Triggered Flows

These Flows are triggered when a platform event message is received and perform automated actions behind the scenes.

Autolaunched Flows

These Salesforce Flows perform actions behind the scenes when they are called by Apex, REST API, another Flow, and more. They do not have a trigger built into them.

10 Best Practices for Using Salesforce Flows

1. Use Salesforce Flows Before Apex (Clicks, Not Code)

Salesforce Flows are highly intuitive and can be very helpful in getting things done quickly and easily. Additionally, they are less expensive to maintain than Apex code, so they can be a more cost-effective option for many organizations.

Salesforce recommends a ‘clicks, not code’ approach to development in order to reduce technical debt in their Salesforce org. Technical debt is the term used to describe the build-up of code and other technology that is difficult or costly to maintain and makes it harder for businesses to scale their solution to a rapidly-evolving business. When a company adopts a ‘clicks, not code’ approach, it means that they are designing their business automation in a way that will reduce the amount of code that is required.

Salesforce Flows are a good idea for businesses that want to future-proof their Salesforce org. By using Salesforce Flows instead of Apex code or other programmatic customization tools, businesses can reduce the amount of technical debt that they accrue over time. Additionally, Flows are easy to learn and do not require test classes to be written for each and every element, as Apex requires a test class to cover 75% of code.

2. Limit Use of Red Elements (Create, Update, Delete, and Get)

Developers need to be careful when using the Create, Update, Delete, and Get elements when designing and building Salesforce Flows to avoid errors caused by hitting governor limits. These limits exist to prevent transactions from slowing down the system (remember, Salesforce is a multi-tenanted environment meaning multiple orgs use the same infrastructure and resources). Developers need to be especially careful when working with Collections and Looping, as using a red element within a Loop is a HUGE no-no and can easily lead to exceeding the governor limits.

3. Develop Your Salesforce Flows in a Sandbox First

Any time you design and build a Salesforce Flow, you should be developing in a Sandbox so that any errors or malfunctions will not affect Production data and can be worked out prior to deployment. You have likely heard the popular saying that was made famous by everyone’s favorite web-slinging superhero, “With great power comes great responsibility”. As a responsible and successful Salesforce admin or developer, you should keep this in mind as well. Salesforce Flows can be extremely powerful, and as a result, require a large amount of responsibility to be taken when building them.

Flows not only create records but also edit and delete them, most of the time without user input. Imagine this sort of automated power being built wrong and deleting valuable information from your Salesforce org – your Flows will be doing more harm than good! For this reason, always (repeat, ALWAYS!) build and test your Salesforce Flows in a Sandbox environment and make sure they are doing exactly what you expect them to do before pushing them to your Production environment.

4. Create Clear, Concise Documentation

It is important to remember you will not be around forever and the business’s logic cannot solely exist in your head. You are likely to have many different jobs in your Salesforce career for many different organizations, and you need to ensure that you have properly informed those who come after you.

Your documentation should clearly explain the purpose of your Flow and how it achieves it. If there is ever a time in the future where your Flows are being rebuilt or combined due to evolutions in the tool itself, or the business requirements change, your documentation should provide a guide for the current admin or developer to do what they need to do.

Your business should have a central repository for all Salesforce-related documentation that admins, developers, or consultants should have access to. This will make it easier for your org to be scaled up or down while reducing issues, as everyone involved should be able to quickly find relevant documentation.

In addition to proper documentation of your Salesforce Flows, you should also get into the habit of populating the Description fields of any element you create inside of Salesforce – including Flow elements. This gives the next admin or developer a good idea of what that particular element is being used for if they ever need to enhance or update the Flow.

This is particularly important for Flow elements that do not use standard terminology or use terminology that may change. Ensuring a clear description of what that particular element is will make it easier when you (or another Salesforce admin or developer) return to the Salesforce Flow in the future.

5. Create Scalable Complex Salesforce Flows Using Invokable Actions and Subflows

If there is a lot of functionality that you find yourself constantly rebuilding in the Salesforce Flows you create, consider building a Subflow that can be leveraged by multiple Flows to save your time in creating and maintaining your Flows.

A Subflow is a smaller Flow that performs a common task. Salesforce’s documentation gives an example of a Flow that collects credit card information or performs authorization of a credit card purchase as an example of a Subflow.

Another way you can enhance your Salesforce Flows with reusable components is to create invocable Apex that can be called from your Flows and use these in multiple places. Remembering that Salesforce prefers a ‘clicks, not code’ approach to development, you should only consider using invocable Apex when the functionality cannot be achieved by using a Subflow.

6. Be Careful of Nulls and Empty Variables

If you do not check for null or empty values throughout your Salesforce Flows, you may be attempting to use something that is not there and cause an error! Particularly after you use a Get Records element, it is wise to create a Decision to make sure that you have gathered the variables you are anticipating to avoid running into errors. Remember, always plan for every scenario when you are building a Salesforce Flow!

7. Learn How to Use Different Kinds of Salesforce Flows

Salesforce Flows have a significantly smaller learning curve than Apex, but are still rather extensive. Once you have learned the basics, you will find it quite valuable to learn how to create all the other types of Flows available to you.

The five types of Flows are outlined above, and each has its own functionality.

8. Avoid Hardcoding Logic, Values, or IDs in Salesforce Flows

Avoid hardcoding your frequently used logic, values, or IDs within your Salesforce Flows to help reduce maintenance of your Flows, Apex, and other automations within your Salesforce org. Utilizing Salesforce features like Custom Metadata for frequently referenced IDs that may change means that when the time comes, there is only one asset that needs to be updated, rather than 10 Flows, 7 Apex Classes, and 38 Validation Rules.

Allowing logic to be dynamically created within your Flows (and other tools like Apex) means you will be able to scale your automations up and down as required by the business. For example, let us say you have an email notification that goes out to the Primary Contact of an Account every 14 days if they have an outstanding balance. A few years down the line, your Sales Manager asks you to create another automation for Accounts that should get notified every 21 days. Some more time passes, and another automation is required for those who need to be notified every 7 days.

If you had designed your logic to send out a notification in X days (where X is a value populated from a field on the Account), it would be as simple as adding a new value to a picklist each time the requirements change, rather than creating a new Flow each time (or even updating the Flow each time).

9. Ensure Errors Are Handled

Ensure that even if something goes wrong, your Users are not left with an ugly error message. If there is a point of failure in your system (i.e. if a variable needs to be populated before your users continue), ensure that a friendly error message is displayed and that your users have the opportunity to go back and perform the actions required.

If your errors are left unchecked, your users will be displayed with an unfriendly ‘unhandled error has occurred’ message, which is never a positive experience.

Also, make sure your users are trained on how to properly use the Flows you have created for them. And if they receive an unhandled error message, make sure they know how to report it to you correctly (train them on retracing their steps and providing contextual information about how they triggered the Flow, where they triggered it from, etc).

10. Connect with the Salesforce Ohana!

Finally, remember that you are not the only person in the world who configures Salesforce Flows. There is a friendly community out there to help you as you learn the new tools, help you learn better ways of leveraging new features as they come out, and can share their solutions with you.

You can enhance your Salesforce Flows with components from the AppExchange, or from open-source sources like UnofficialSF. There are Salesforce training resources like AutomationChampion that are there to help make your journey easier, and you can always leverage the Trailblazer Community when you run into a problem.

Testing Your Salesforce Flows Using Debug

Unlike Apex, Salesforce Flows do not require a Test Class or a specific percentage of code coverage to pass before they can be deployed into a Production environment. That being said, it is still absolutely imperative that you are testing your Salesforce Flows thoroughly before deploying them to Production.

Salesforce has observed the requirement to thoroughly test a Flow before deployment and has created the Debug tool. Using the Debug tool, you are able to ensure your Salesforce Flow works and does not negatively impact any other functionality within your org before letting it manipulate real business data.

Using Salesforce Flow with Inspire Planner

You can use Salesforce project management tools like Inspire Planner to enhance your Salesforce Flow experience as well. For example, let us say your business wants an easy way to create a standardized project template inside Inspire Planner to guide your Admins, Developers, and other Salesforce Professionals on your business’s standardized way to create, test, and document Salesforce Flows.

You can create stages for each of your major steps, like Researching Business Need, Building Flow (and Best Practices on how to do so, which you can feel free to pull straight from this article!), Documenting the Flow, Testing the Flow, and finally Deploying the Flow.

Another common scenario is to build a Salesforce Flow to automatically create Projects in Inspire Planner from a template when Opportunities move to the Closed/Won stage (e.g. customer onboarding or software implementation). This new project will have all the required information pre-populated from the template, such as all the tasks, predecessors, files, resource roles, and more.

When You Should Avoid Using Salesforce Flows

Salesforce always prompts administrators and developers to use a ‘clicks, not code’ approach to building on the Salesforce platform, so why would we be suggesting reasons to actively avoid using Salesforce Flow? The answer is quite simple, in theory: As amazing as Salesforce Flow is, it is, quite simply, not Apex or a Lightning Web Component.

Salesforce has built entire frameworks and coding languages to allow developers to extend the functionality of the system, and over time they have also created declarative tools with the intention to empower those without a background in IT to do the same.

Apex is an advanced programming language that supports more complex collection types (like Sets and Maps), as well as support for more complex data processing. If you ever need to use a Map to compare a set of data using a key, this is where you will need to move away from Flow and use Apex instead (even if you create an invocable Apex action and handoff that particular section of your Salesforce Flow to do the more complex processing).

Aura Components and Lightning Web Components are two frameworks that Salesforce has created to allow programmatic developers to create reusable user interface components to be used on the Salesforce platform. Screen Flows allow you to create screens using a number of Standard components (Input Fields, Display Text, etc), but these interfaces remain quite basic without a custom component being added on top (for example, the Data Table screen component by UnofficialSF).

Additional Resources on Salesforce Flows

If you are trying to learn more about Salesforce Flows, here are some great resources for you:

• Salesforce Flows – Learn Salesforce Lightning Flows Fast
• Salesforce Flows: The Complete Guide to Lightning Flows
• Salesforce Lightning Flows
• Ultimate Salesforce Flow Foundation Course

Summary

There you have it – your one-stop shop for all things Salesforce Flow. Hopefully you have learned a few new tips and tricks for providing the most value to your business, users, and ultimately your customers by following some best practices while working with Salesforce Flows.

And if you are looking for some inspiration for using Flows in your Org, you can start with our 5 Simple Salesforce Flow Ideas with Big Impact.