10 Salesforce Flow Best Practices

Share this article...

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 10 Salesforce Flow best practices that I follow regularly 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.

2. Consider Using Subflows

A Subflow is an Auto-launched 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. 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.

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 hardcode them. 

One of the main reasons you wouldn’t want to hardcode 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 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.

7. Utilise 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. Use After-Save Flow Instead of Process Builder/Workflow

This is another of the three key takeaways from the Record-Triggered Automation page of the Salesforce Architects Guide. Process Builder is significantly slower than Flow at processing a transaction. Workflow Rules are an entirely different system altogether and also extremely slow in comparison with Flow. If your org is fairly new and you’ve only built automations using Flows, this makes your job easier – keep using Flows! If you’re in an org with some legacy automation – existing Processes and Workflow Rules – it would be well worth your time to plan a migration to Flow to simplify your development going forward.

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 8, 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 utilise Apex rather than Flow to complete your task.

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 utilise and many other Salesforce users and partners that are willing to help further.

One thought on “10 Salesforce Flow Best Practices

  1. Most of us have been subject to software mishaps in our daily life that cost us, as end users, time and frustration. These best practices, in the end, increase the reliability of performance, which is something often lacking these days. Reinforcing testing and the use of sub flows are especially welcome reminders when pressure is on to meet deadlines.

Add Comment