Documentation

Good documentation helps others (and your future self) quickly grasp the flow's purpose. Flows solve real business challenges, so leaving clear notes is key for maintaining them over time.

Clarify the Flow’s Purpose Fill in the description with the problem the flow addresses, the objects it interacts with, and where it’s triggered. If possible, note how it ties into the business process and who it impacts. Have a JIRA or Story ID? Include that as well!

When naming a flow, it should clearly describe the action it performs as specifically as possible. For Record-Triggered Flows, the name should reflect what triggers the flow. The flow description should include key details such as the requirements for it to run, the entry conditions, the specific functionality it performs, and its output.

‍

Maintain Consistent Naming Stick to naming conventions for variables and elements, and describe what each one captures. Consistency, like using CamelCase, makes it easier for anyone to follow later.

Explain Every Step Add short notes to explain what each element does. This is especially helpful when using workarounds, advanced functions, or Apex invocables, ensuring others can understand and take over if needed.

Assess Your Automation Strategy

Every Salesforce object should have a defined automation strategy, ideally using a single tool per object. Mixing Apex triggers with flows or combining process builders with record-triggered flows can lead to performance problems, unexpected outcomes, and increased technical and documentation debt.

Utilize Subflows for Efficient Flow Management

A Subflow is an Autolaunched Flow that can be triggered by one or more parent flows. Typically, it includes variables for input and output, allowing parent flows to pass data into the Subflow, perform actions or calculations, and receive results back.

Subflows are particularly useful when dealing with complex calculations or actions that might need to be reused across multiple flows. By creating these actions once in a Subflow, you simplify the overall process, reduce the risk of human error, and minimize maintenance and testing time. This makes your declarative programming more efficient and consistent.

Subflows streamline your flows, making them reusable, scalable, and easier to manage. Consider using subflows in these situations:

• Re-use: If you're repeating actions within or across flows, a subflow can handle them—similar to a ‘Helper’ class in development.
• Complex Processes: For flows with branching logic or multiple steps, use a main flow to launch subflows (e.g., 'Manage Contact Data' launching subflows like 'Associate Contact to Companies').
• Organization: If your flow is complex or cluttered, break it into subflows to make it more manageable.
• Permission Handling: Use subflows with elevated permissions to access data that the main flow's user can’t reach.

Benefits:

• Make changes once instead of in multiple flows.
• Keep flows clean and organized.
• Centralize org-wide behaviors, like sending consistent error messages.

Considerations:

• Subflows require more collaboration and testing.
• Debugging can be harder with subflows.
• Avoid overuse, as too many subflows can complicate the user experience.

Use Before-Save Flows for Same-Record Updates

It's more efficient to make changes to a record before it is saved, rather than saving it, applying another change, and then saving again. This approach reduces transaction time and minimizes the number of DML statements in a transaction.

Use Schedule-Triggered Flows and Asynchronous Paths

Schedule-Triggered Flows automate record updates at regular intervals, reducing manual work and can be scheduled for after-hours runs to minimize system impact. However, it’s essential to consider how scheduled flows affect governor limits.

When you choose the record scope, each retrieved record generates one flow interview, with a limit of 250,000 interviews per 24 hours based on user licenses.

Avoid specifying the same records within the flow scope, as this can multiply the workload and quickly exceed limits. If you need tighter control over limits, opt for an invocable action or use a scheduled job with Apex. For specific record date scenarios, a scheduled path in a record-triggered flow may provide better flexibility and adjustable batch sizes.

‍

Asynchronous paths, on the other hand, queue actions to run later when the system has capacity, helping to reduce immediate processing load. Both methods help optimize performance and system efficiency by distributing tasks over time.

Screen flows: Watch the flow context

Be mindful of the context when building screen flows, especially for external users on Experience Cloud sites. For security:

• Use system context only in subflows to retrieve or execute data, not in the entire flow.
• Avoid using "Store all fields" in Get Records elements for screen components, as it risks data leaks in browser tools.
• Don’t leave system mode enabled on screens for guest users.
• When updating records, update specific fields instead of entire record collections from screen components to avoid manipulation.

Also, remember that some Lightning components, like Lookup and File Upload, don’t respect system context, so ensure users have proper permissions. Use custom permissions or flow controls to handle access.

Enhance Flow with Invocable Apex

While Flow Builder offers many features, there are times when your flow requires capabilities beyond the standard elements. In such cases, you can use an Apex action to call an Apex class from your flow. Examples include generating a quote PDF or retrieving a list of Opportunities by passing Account IDs.

‍

To set this up, define your invocable methods in Apex using the @InvocableMethod annotation. Here are some key points to keep in mind:

• Limit to one @InvocableMethod annotation per Apex class.
• Supported inputs and outputs include primitives, SObjects, Apex-defined classes, and lists.
• Ensure your method is bulk-safe, as input and output will always be in list format.

Avoid Overloading Flows with Hard-Coded Logic

Hard coding logic in flows slows development and reduces flexibility. Instead, store logic in centralized places like Custom Metadata, Custom Settings, or Custom Labels so other automation tools (Apex, Validation Rules, flows) can use it too. Use these methods when:

• Referencing the same data in multiple places.
• Managing mappings (e.g., states to tax rates, record types to queues).
• Handling information that changes frequently.
• Storing reusable text (task descriptions, notifications).
• Storing environment-specific variables (URLs, owner IDs).

This approach keeps flows cleaner and more dynamic, as seen when using Custom Metadata to map record types to queues in an After-Save Case flow.

The power of Flow lies in its ability to retrieve specific information, like Record IDs or Record Type IDs, without needing to hardcode them. Hardcoding IDs can cause problems when moving between environments, as these IDs often change. For instance, if you create a new Record Type in a sandbox and deploy it to another environment, the Record Type ID will differ.

To avoid this, it's better to access such IDs dynamically. If hardcoding is necessary, consider using a Constant, which holds a fixed value, making it easier to manage and maintain across environments.

Custom Metadata Type+

Custom Metadata Types (CMDTs) allow you to store and manage data as part of your org's metadata, meaning they persist across sandbox refreshes and can be deployed via change sets. CMDTs are ideal for reusable functionality and centralizing key data like IDs or configurations used across flows and other automation tools. The best part is that CMDT records are metadata, making them ideal for consistency and reusability. However, avoid using CMDTs if a simpler Get Records query can retrieve the necessary data.

Custom Settings

Custom Settings act like custom objects but store org-wide data, making them ideal for storing configuration data or environment-specific values like sandbox URLs or production URLs. They can be used in flows, validation rules, and processes. However, Custom Settings do not persist across sandbox refreshes, requiring manual export and re-import after each refresh, which can add maintenance complexity compared to CMDTs.

Custom Labels

Custom Labels store reusable text across the Salesforce org, and they’re useful for managing text that appears in flows, validation rules, and error messages. They are particularly effective for multilingual orgs or when managing text that changes frequently. However, for complex data mappings or reusable logic, CMDTs or Custom Settings are more appropriate because Custom Labels are limited to text values.

Include fault paths in flows:

When building a flow, plan for what happens if an error occurs. Decide who gets notified or whether a log should be created. A common mistake is not setting up fault paths, which handle errors by showing an error screen or sending email alerts.

Faults and errors are inevitable when working with flows and automation, so handling them properly is crucial. Ensure users receive clear error messages when something goes wrong. For example, if a query returns no results, provide specific guidance instead of just showing a generic “unhandled error” message.

Planning for faults helps create a smoother user experience. Even after a Flow is live, new errors may appear. It's essential to address these promptly so that future users encountering the same issue receive helpful error messages, explaining what went wrong and what actions to take next.

‍

Use Entry Criteria

‍
Be precise with your entry criteria to avoid triggering automation on record changes that won't be utilized in your flows. The Flow team has greatly improved the efficiency of flows that don't meet these criteria, addressing a significant issue previously faced with Process Builder. This, along with the order of execution challenges, helps mitigate the risks of excessive automation on an object.

When it comes to benchmarks and performance, always opt for Before-Save flows when updating the same record that triggered the automation. According to the Architect’s Guide to Record-Triggered Automation, Before-Save flows are significantly faster than After-Save flows and nearly as efficient as Apex.

Avoid these common flow-building mistakes:

1. Not checking for null values: Always include a Decision element after a Lookup/Get Records to check for null results. If you assume a record exists without verifying, you risk causing errors or unintended actions.
2. Empty collections: Some components output empty collections, which aren't "null." Use an Assignment element to convert the collection into a number for easier decision-making.

Looping mistakes to avoid:

Never execute a DML statement (Get, Update, Create, or Delete) inside a loop. Repeatedly using these actions within a loop increases the risk of hitting governor limits, as it’s harder to control how often they’re executed.

Instead, if you need to loop through and update multiple records, use a collection variable to store the changes and perform the DML operation outside the loop. This approach helps you manage the number of DML operations and ensures better performance.

‍

Complex formulas: Avoid complex formulas in batch flows, as they can lead to performance issues. Simplify where possible for smoother execution.

Don't create a Flow for every solution.

 If you can achieve your goal with a formula or report, opt for that instead of automation. Use automation only when necessary! For example, if you need to display the Account Site on a Contact record, use a formula field rather than a record-triggered Flow. Similarly, when tasks like managing duplicate platform events are better suited for Apex Triggers, it's best to use them instead.

Flow isn’t always the best option for automation. While Flow is efficient, there are faster tools like Apex that might be better suited when transaction times are an issue. In some cases, specialized tools like OmniScript for Salesforce Industries may be a more fitting solution. Additionally, combining tools can offer a more robust approach, such as embedding a custom LWC within a Flow to gather user data and then using an invocable Apex action to send data to another system. Always consider the most suitable tool for the task at hand.

Summary

Flows are a powerful tool for automating tasks in your Salesforce org, but it's easy to run into challenges if you're not aware of potential pitfalls. The good news is that Salesforce offers endless opportunities to keep learning. There are plenty of resources available, and a supportive community of users and partners ready to assist along the way.

‍