Introduction:
Salesforce flows are vital for streamlining tasks and building bespoke processes in your Salesforce organization. Knowing their constraints is vital for ensuring smooth and effective flow performance. This article highlights the main flow limitations and provides tactics for optimizing your flows to stay within these boundaries.
General Flow Constraints:
Salesforce flows can be utilized in Salesforce Classic (in certain organizations) and Lightning Experience. They are available in Essentials, Professional, Enterprise, Performance, Unlimited, and Developer Editions.
Why Are There Limitations?
Salesforce operates in a multitenant environment, meaning multiple organizations share the resources of the same instance. To ensure fair resource distribution and prevent any single organization from consuming excessive capacity, Salesforce imposes these limitations to manage usage for each client.
Understanding Flow Interviews and Transactions:
Flow Interviews and Transactions:
A flow interview represents a running instance of a flow, essentially one complete execution of that flow. Conversely, a transaction is a collection of operations executed as a single unit. A flow interview is one type of operation among others like triggers and escalation rules, meaning it always operates within a transaction. Multiple flow interviews can occur within a single transaction due to Flow bulkification.
Conversely, a single flow interview can span multiple transactions based on the definition of a “single unit.” It’s crucial to note that a flow interview is not the same as a transaction, and each has its own set of limitations.
SOQL and DML Operations:
SOQL (Salesforce Object Query Language) retrieves data, while DML (Data Manipulation Language) modifies data. In Flow, only data elements (the pink ones) trigger these operations – “Get Records” uses SOQL, and “Create/Update/Delete Records” uses DML.
Flow Interview Limits
- Executed elements at runtime per flow: 2,000
Each flow interview can execute a maximum of 2,000 elements. If a loop is involved, the elements within it will multiply by the number of iterations. For instance, 100 records entering a loop with two elements will result in 200 elements executed.
Transaction Limits
- Total SOQL queries issued: 100
A maximum of 100 data elements can retrieve data. - Total DML statements issued: 150
A maximum of 150 data elements can modify data. Elements in a loop will multiply, leading to the practice of “No Pink in Loop.” - Total records retrieved by SOQL queries: 50,000
Up to 50,000 records can be retrieved. - Total records processed by DML statements: 10,000
Up to 10,000 records can be modified. - Maximum CPU time on Salesforce servers: 10,000 milliseconds
Server CPU time is capped at 10,000 milliseconds (10 seconds). - Total duplicate updates in one batch: 12
A record can only be updated a maximum of 12 times.
Avoiding Flow Limits
To avoid hitting these limits, construct flows efficiently. If limits are still reached despite best practices, consider generating multiple flow interviews or transactions.
Building Efficient Flows
- Minimize Data Elements Usage: Limit the use of data elements.
- Avoid Data Elements in Loops: Skip loops if possible.
- Strict Entry Criteria: Set stringent criteria for entries.
- Utilize Variables and Assignment Elements: Use these for updating records efficiently.
How Many Flows Should Have Per Object?
Evolution of the “One Flow Per Object” Rule
You may have encountered the guideline, “one flow per object,” but its relevance has evolved. Initially, Salesforce promoted this rule to ensure operations were executed in a specific order within a single flow. However, as Salesforce introduced new features, this advice has shifted to accommodate a broader range of organizational needs and complexities.
Salesforce’s Updated Guidance:
Salesforce’s early automation advice, rooted in the era of Process Builder, advocated for a single flow per object to manage operation order. However, with the Spring ‘22 release and the introduction of Trigger Order functionality, actions can now be sequenced across multiple flows. This change acknowledges that the “one flow per object” rule is not always practical given diverse business contexts.
Creating a Record-Triggered Flow Strategy:
As you’ve read, there are two main methods for creating Record-Triggered Flows within your org:
- Option 1 utilizes the Entry Criteria and Flow Trigger Explorer to make it easier to manage multiple smaller Flows, which will lead to performance improvements (particularly in orgs with large data volumes).
- Option 2 follows the rule of three. This approach is still endorsed by Salesforce themselves in certain circumstances (depending on your license and what your business needs are). It follows a number of best practices that are well-known beyond even the realm of Flow.
Triggering Record-Triggered Flows :
Record-Triggered Flows can activate on Create, Update, Create or Update, or Delete actions. Consequently, the foundational number of flows per object has expanded to three distinct types:
- Before Create or Update
- After Create or Update
- Before Delete
Adding More Flows Per Object:
Starting with these foundational flows, additional flows may be necessary to manage complex processes efficiently. Large, monolithic flows can become cumbersome, requiring extensive regression testing and increasing technical debt. Splitting flows into smaller, more manageable units can be more efficient.
For example, different business units might need autonomy over their automations. Admins would coordinate with these units to ensure their specific needs are met while maintaining overall system efficiency.
Setting Trigger Order:
Since the Spring ‘22 release, you can define the order in which Record-Triggered Flows execute. This flexibility allows for multiple flows per object, effectively replacing the “one flow per object” rule with a more nuanced “X flows per object” approach, enhanced by trigger order settings.
Transitioning from Process Builder to Flow:
The transition from Process Builder to Flow introduces significant improvements. Unlike Process Builder, Flow allows for separating “before” and “after” triggers, adding considerable value. The recommended approach is to rebuild and enhance automations rather than using migration tools that merely copy existing processes.
Rebuilding provides an opportunity to reassess and optimize your automation landscape, though it requires collaboration and effort from various stakeholders within your organization. This method ensures a more efficient and scalable automation framework tailored to your specific needs.
Summary :
Salesforce Flow limits are in place to make sure each client can utilize the resources fairly. In general, there are two sets of limitations (per flow interview and per transaction), which are two different concepts. To avoid these limits, build the flows as efficiently as possible, utilize the bulkification feature, or split the transactions. Creating one Flow per object will enable you to achieve flexibility, create reusable Flows, and manage all your Flows for a given object in one place. Follow Naming convention for that same flow can be reuse.