Salesforce Flow Best Practices
Best practices in flow revolve around principles that enhance low-code quality, maintainability, and collaboration. Key practices include, but are not limited to, building clear and concise automation with meaningful resource names to improve readability and consistently adhering to standards for uniformity.
Overall, following best practices leads to more efficient and effective automation.
Antipatterns in flow refer to common practices or solutions that may seem beneficial but ultimately lead to poor software design, increased complexity, or maintenance challenges. They are the opposite of best practices and often arise from attempts to solve problems without fully understanding the implications. Recognizing and avoiding antipatterns is crucial for creating clean, efficient, and maintainable code.
While reviewing legacy flow automation is very different from reading and reviewing code, the visual builder flow canvas presents opportunities to spot antipatterns easily.
I gathered the antipatterns I have seen throughout the years and created a slide-set for a comprehensive list. This list is not meant to be the definitive list. I hope it will start fruitful discussions around the topic, which may yield better flow automation quality in the ecosystem.
This post will start a best-practice blog post series. Each item on the list will receive a comprehensive post, and I will link it to this master post upon completion.
Without further ado, let’s dive into the list:
- Can You After-Save When You Can Before-Save? Consider performing the same record updates in before-save flows.
- Can You Use DML or SOQL Inside the Loop? While there are situations where you may need to break the rule, DMLs and SOQLs (Create, Update, Delete, and Get) should be placed outside the loop.
- Is Your Salesforce Flow Too Big? Consider a modular approach and leverage subflows for an easily maintainable structure when your flow becomes too big.
- Can You Start With a Loop Inside Your Schedule-Triggered Flow? When you loop immediately after a start element with an object associated, you will loop for every record the flow launches on. This design is not often intended and will potentially generate faults.
- Can You Loop Inside a Loop? While this may be necessary in certain situations, it is often a sign of a weak design. Loops inside loops will cause a high number of iterations, hurting performance and usually yielding faults.
- Can You Start With a Decision Inside Your Record-Triggered Flow? Starting your record-triggered flow with a decision creates two or more distinct paths inside your automation, which you can split into multiple flows with tighter start element conditions. The latter often is the better-performing design.
- Formula Resources in Criteria Conditions—Yes or No? Instead of inserting formula resources in criteria for decisions and updates, you should consider building multi-line conditions combined with AND and OR operators.
- Can Your DMLs Have Criteria Conditions Other Than Id? Updates that include conditions beyond specifying the Id of the record consume one SOQL and one DML against your execution governor limits; ensure your condition is necessary.
- Can You Leave Unused Input and Output Variables? Mark your variables as available for input and output only when necessary for security reasons.
- Is Your System Context Usage Necessary? Heavy-handed use of system context without sharing can cause unwanted changes in your database. This increases the harm caused by a potential attacker running the flow.
- Should You Use Fault Paths? Your DMLs, SOQLs, and Actions need a fault path to ensure the whole transaction does not fail. Fault paths can offer custom messages and alternative routes, preventing complex system fault messages from being displayed to the user.
- Should You Use Roll Back Records In Screen Flows? Roll Back Record element provides a way for you to roll back the recent DMLs, and ensures that half-baked record updates don’t persist in the database.
- Is Hardcoding Ids a Good Idea? Hardcoded Ids are potential points of failure especially when deploying flows between unconnected environments like scratch orgs.
- What Is The Best Way Of Checking Record Types in Record-Triggered Flows? You can check for record type developer name or name in your record-triggered flow start element without needing a get element inside your flow.
- Should You Hardcode Business Logic In Your Flow? If there is frequently changing business logic in your flow, the preferable approach is to build this on a table outside your flow and have SMEs update the reference table.
- Are Your HTTP Callouts and Outbound Messages on an Async Path? Salesforce requires integration messaging to execute on an async path. In schedule-triggered flows, the wait element provides a similar function.
- Is Your Flow Comparing and Processing Collections? When you go down into the related records, find junction objects, and perform enhanced operations with collections, you may be better off leveraging Apex.
- Are Your Email Actions on an Async Path? Perform email actions and create trivial object records for internal follow-up on an async path. This ensures that the main part of the execution does not slow down or stop due to performance or error reasons.
- Other Miscellaneous Items: Testing, naming, comments, documentation, null check etc.
Let’s start with the obvious: Build in the sandbox, debug, and test your flows very well. Create good documentation for your flows, add comments and descriptions, and follow naming conventions.
Here are the slides I created for this topic:
View and download Salesforce Flow Antipatterns and Best Practices here.
I presented these items at London’s Calling, Apex Hours, and Trailblazer User Group Meetings.
Everyone is welcome to comment on the blog posts, and I will read them and respond to them.
Explore related content:
6 Things You Can Do With The Transform Element
Top 9 Salesforce Winter 25 Flow Features
#AfterSave #Antipatterns #BeforeSave #Element #HowTo #Loop #Record #RecordTriggered #Update
