10 Salesforce Flow Best Practices

Salesforce Flow is the most powerful declarative automation tool that Salesforce has built. We all know that “with great power comes great responsibility” – so, it’s important to learn not only how to build using Flow Builder but also learn what to avoid (what to do and what not to do).

Here are the best Salesforce Flow practices I regularly follow when developing my flows. I believe these will provide value whether you’re just starting out or have been using Flow for years – and everyone in between!

1. Always Test Your Flows

I often preface my tutorials with “Always build in a sandbox or developer environment”, and this one is just as important. Make sure you test your solution thoroughly before pushing it into Production.

Flow Builder has a built-in debug tool that you can use to test your flows before activating them. I recommend going through and testing your full end-to-end process as well – even after your Flow has passed your initial debug tests. Sometimes, you’ll find additional issues in the actual process that you need to clean up before deploying. It’s always better to over-test than to under-test.

Additionally, Flow Builder has added the ability to create and reuse structured testing, similar to Apex test classes. Flow Builders can simply identify what their expectations are and create the Flow tests, then run them either one by one or together as a batch.

2. Consider Using Subflows

A Subflow is an Autolaunched Flow that is called from one or more parent flows. They often have at least one variable that has been made available for input and another that has been made available for output. This is so that the parent Flow/s can pass information into the Subflow, have a calculation or set of actions performed, and have a value returned.

Occasionally, you may build a Flow that has a lot of complexity and runs a lot of calculations. You may even build some sort of complex calculation that you’d like to use in another Flow, and this is a perfect example of where subflows would be valuable. Creating a single set of complex actions once and allowing multiple flows to take advantage of it makes your declarative programming much easier and faster. It also removes a lot of the room for human error while reducing maintenance and testing time.

3. Never Perform DML Statements in Loops

I harp on about this a lot, too: never ever perform a DML Statement inside of a Loop. This means never performing a repetitive Get, Update, Create, or Delete (the pink data elements) inside of a Loop. This is so that your risk of hitting a governor limit is significantly reduced as you’re able to control the number of times one of these data elements is used.

If you ever need to loop through and update multiple records, always remember to assign a collection variable and perform your DML Statement outside of the Loop.

4. Document Your Flows

It is inevitable that your Flow will be viewed by other Salesforce Administrators and potentially consultants. You should always create supporting documentation to make it easier for them to understand what your Flow does and the key elements and functions that it performs to make their job of maintaining the org easier.

One simple thing you should do when building or editing a Flow is to ensure that each description value is filled out with a meaningful description of what that particular element is used for. This is one of the simplest and yet most valuable types of documentation you can do, as it is surfaced right there in the Flow Builder. If your company hires a new Consulting Partner to make some modifications or if your internal Salesforce or IT teams expand, then having this readily available information is going to be invaluable for them.

You should also consider mapping out your flows before you build them. You can use a tool like Draw.io or Lucidchart to map out how your Flow will work prior to building to ensure you’re not doubling back on yourself partway through.

Bonus: If you’re a fan of Lucidchart, you may be curious about this Idea that proposes the ability to export flows directly into Lucid to speed up documentation.

5. Never Hard Code Ids (Use Constants if You Must)

The beauty of Flow is that it has the ability to reach out and get specific information. As a result, you should be able to access things like Record Ids or Record Type Ids with ease, without having to hard code them.

One of the main reasons you wouldn’t want to hard code Ids is because they will often change when shifting from one environment to another. For example, when you develop a new Flow in a sandbox, you’ll be testing it against sandbox data. If you’ve created a new record type in a sandbox and push it to a new environment alongside the Flow, the Record Type Id will change when it is recreated in the new environment.

If there is a scenario where you need to hardcode anything, consider using a Constant. Constants are like variables, except they’re designed to simply hold a non-variable value that always stays the same.

6. Plan for Faults (and Handle Them)

​​Faults and errors are bound to happen when working with flows and other automation. As such, it’s important to make sure they’re handled correctly. Make sure your users are presented with detailed error messages when unexpected actions occur (for example, if a record is queried and no result is returned, let the user know that they may need to take a different action rather than just showing them a standard “an unhandled error has occurred” error message.

The reality is that faults do happen, and it’s better to plan for and manage those faults as best as you can to ensure a smooth and pleasant experience for your end users. Even after the Flow goes live, you may find users experiencing new errors that they’ve not come across before. It’s important to handle those as well so that the next time someone else does the same set of actions that lead up to the error, they’re either guided away from doing it or provided with a clean error message explaining what went wrong, why, and what they should do next.

7. Utilize Before-Save Flows for Same Record Updates

This is one of the three key takeaways from the Record-Triggered Automation page of the Salesforce Architects Guide. It is better to perform another change to the record before it is pushed into the system, rather than saving it, assigning another change, and then saving the record a second time. This simply limits the transaction time and the number of DML statements per transaction.

8. Make Use of Schedule-Triggered Flow and Asynchronous Paths

Schedule-Triggered Flows allow you to run a set of actions across records on a regular basis. This can be useful to save the time your users spend on manual updating of records, and can be scheduled to occur outside of business hours to reduce impact on the system during this time. Keep in mind there are a number of considerations that are specific to schedule-triggered flows that you’ll need to keep in mind.

Another option to help reduce the load on the system is to consider creating an asynchronous path in your flows. Simply put, an asynchronous path allows your initial execution to ‘queue’ actions to occur later when the system is freed up.

Both of these options have their core reason for existing and are options when it comes to reducing processing time and load on the system.

9. Flow Isn’t Always the Best Idea

There are times when building a flow may not be the correct move. As with point number eight, there is an order of magnitude for how slow a specific automation tool is. Flow is fast, but there are other tools like Apex that are much faster. If you’re seeing issues related to a transaction taking too long to process, you may need to utilize Apex rather than Flow to complete your task.

There are also scenarios where you may have access to a specialized tool that is fit for purpose, such as OmniScript with Salesforce Industries. Flow is great, but special-fit tools are often better. Additionally, you may find that you need to use a combination of tools together to meet a certain requirement. For example, you can build a custom LWC that you then embed within your Flow to capture information from users. Later in the Flow, you can call an invocable Apex action to send data to another system.

10. If You Get Stuck, Ask the Trailblazer Community!

No matter what your problem is, no matter how complex or nuanced, you can always reach out to the Salesforce Community to help. The Trailblazer Community is a great place to start. There are thousands of passionate Salesforce advocates willing to help where they can and provide answers and assistance where required. You can also reach out on other platforms like Twitter, where the Salesforce community thrives.

Summary

Flows are a wonderful way to create automation within your Salesforce org. That said, there are lots of traps and pitfalls that you can fall into along the way if you’re not educated on how to avoid them. The beauty of Salesforce is that you can always learn more – there are stacks of learning materials out there that you can utilize and many other Salesforce users and partners are willing to help further.

Looking to master the foundations of Flow? I’ve got you covered in the Ultimate Salesforce Flow Foundation Course!