#salesforcedevelopers — Public Fediverse posts

Master Custom Batch Sizes for Schedule-Triggered Flows

The wait is finally over! Summer ’26 has officially arrived, and while some might call this release “light,” those of us deep in the automation trenches have found some gems. If you’ve spent any time on Salesforce Break, you know I’m passionate about Flow performance and scalability. That’s why my #1 item for this release is the arrival of custom batch sizes for scheduled flows.

This is a functionality I’ve been asking for for years, and it finally got rolled out to our Flow Builder toolset. Let’s get into why this matters, the technical hurdles it solves, and how you can use it to build more resilient automations.

What is a Schedule-Triggered Flow?

Before we get into the new settings, let’s define the foundation. A Schedule-Triggered Flow is a type of background automation that launches at a specific time and frequency (once, daily, or weekly).

Unlike Record-Triggered flows that fire the moment a record is edited, these flows are often used for “maintenance” tasks, such as:

• Sending follow-up emails for stale opportunities.
• Updating status fields on records that have reached an expiration date.
• Nightly data cleanups or syncing with external systems.

You define a start date, time, and an optional object with filter criteria. Salesforce then finds every record in your org that meets those criteria and runs a “flow interview” for each one.

Understanding Bulkification and Batching

Efficiency is at the heart of Salesforce’s architecture. To handle thousands of records without crashing the servers, Salesforce uses bulkification and batching.

By default, when a scheduled flow runs, Salesforce groups records into batches of 200. For example, if you have 300 accounts that need updating, Salesforce won’t run 300 separate transactions. Instead, it creates two transactions:

1. Transaction 1: Processes 200 records.
2. Transaction 2: Processes the remaining 100 records.

While this is great for overall system efficiency, it can lead to significant problems when your automation logic is complex or touches sensitive data.

The Danger Zone: Governor Limits and Errors

To ensure no single process hogs all the resources in a multi-tenant environment, Salesforce enforces Governor Limits, strict “usage caps” on things like the number of SOQL queries, DML statements (updates/inserts), and CPU time allowed in a single transaction.

When you process 200 records at once in a single transaction, the “math” of these limits adds up quickly. If your flow performs a few queries per record, multiplying those by 200 can easily blow past the 100-query limit, resulting in a dreaded `System.LimitException`.

Here is another potential issue: One of the most common, and frustrating, issues we face is record locking. When Salesforce updates a record, it “locks” that record to prevent other processes from changing it at the same time. It also locks the parent (master) for this record.

Let’s say you have a custom course record in Salesforce, and you have a cohort record under it. The relationship is master-detail. When Salesforce updates a cohort record, it will attempt to lock both records first. If it can’t lock these records, the system will throw an error.

The Error Scenario:

If multiple batches of 200 contain child records that all belong to the same parent, Transaction A might try to lock the parent to update cohort 1. Simultaneously, another part of the batch (or a parallel transaction) tries to lock that same parent to update cohort 2. The second attempt fails because it cannot “reach in” and get the lock, resulting in an UNABLE_TO_LOCK_ROW error.

The Solution: Custom Batch Sizes

In Summer ’26, we finally have the control to mitigate these issues. Under the “Select Object” settings of a scheduled flow, you can now enter a custom number for the records processed at the same time.

The Default: 200 records.

The Power Move: You can decrease this number, even down to 1.

Why set a batch size of 1?

If you are experiencing frequent locking errors or hitting CPU limits, running the automation “one-by-one” (each transaction processing a single record) ensures that the parent record is only locked for that specific record’s update and then immediately released. This will decrease the possibility of locking errors.

Another potential solution for locking issues is sorting by parent before updating child records. Since we cannot sort records by Parent ID in a schedule-triggered flow, decreasing the batch size is often your only tool to prevent parent-record locking conflicts.

Since scheduled flows often run at night or on weekends when user activity is low, the increased total processing time is usually a fair trade-off for 100% reliability.

Best Practices and Recommendations

To get the most out of this new feature, keep these recommendations in mind:

1. Identify High-Risk Objects: Pay extra attention to flows running on Task, Event, Contact, and Opportunity objects, or any custom object that is a child in a Master-Detail relationship, as these are high-risk for locking issues. Remember that standard object relationships are not really technically classified as master-detail, but they could act like one in some respects. These are special relationships that have their own rules. For example: Account is not a required lookup for Opportunity, but you can still add a rollup summary field to the Account for the Opportunity.

2. Monitor Your Error Rates: Keep an eye on the new Element Error Rate column in your Flow list view. If you see a high percentage of errors on a scheduled flow, it’s a prime candidate for a smaller batch size. Disclaimer: This is a brand new functionality, and I have not played with this, yet.

3. Test the “Middle Ground”: You don’t always have to drop to a batch size of 1. If 200 is too high, try 50 or 100 to balance speed and stability.

This update is a huge win for Salesforce Admins and Architects alike. It provides the granular control we need to ensure our “heavy lifting” automations run smoothly without constant manual intervention or error emails.

Take Control of Your Automations

The arrival of custom batch sizes in Summer ’26 is a testament to Salesforce listening to the community’s “real world” pain points. While it might seem like a small setting in the Flow Builder, it is a massive architectural lever for those of us responsible for high-volume data integrity.

No longer are we forced to “hack” our way around governor limits or cross our fingers that record locking doesn’t tank our nightly cleanups. We finally have the precision to tune our automations like a high-performance engine. So, take a look at your most troublesome scheduled flows, experiment with those batch sizes, and turn those “failed flow” emails into a thing of the past. Happy flowing!

A quick heads-up: this feature is specific to the Summer ’26 release.

Explore related content:

What’s New in the Salesforce Mobile App: Summer ’26 Release

11 Flow Updates in Summer 26 Release

Get Your Org Ready: Summer ’26 Admin Highlights

Field Access Summary

#HowTo #SalesforceAdmins #SalesforceDevelopers #SalesforceRelease #SalesforceUpdate #Summer26 #Tutorial

Formula Resources in Criteria Conditions—Yes or No?

Salesforce Flow is a powerhouse for automation. And when it comes to building smart, dynamic Flows, Formula Resources play a critical role. They compute values for create, update and action elements, and calculate parameters to compare to in criteria conditions. But how exactly do they work? And where should you use them?

In this post, we’ll break down their use and explore whether we should be using them in criteria logic across various Flow elements.

What is a Formula Resource?

A Formula Resource in Flow is like a mini-calculator that evaluates to a single value (text, number, Boolean, or date) based on logic you define. Think of it like a formula field on an object, but used inside your Flow instead of the database.

Formula Resources use the same syntax as formula fields, including functions, operators, and references to variables or record fields.

Where Are Formula Resources Used?

You can use them in many flow elements, such as:

Decision Elements

You can use Formula Resources in Decision outcomes to:

• Evaluate complex conditions in a clean and reusable way.
• Reference a single Boolean formula instead of adding it to multiple outcomes.

Example: You might define a Formula Resource like: {!IsHighValueOpportunity} = {!Opportunity.Amount} > 100000 Then in your Decision element, you simply check if IsHighValueOpportunity = TRUE.

Update Elements

You can use formula resources in two ways in update elements:

• On the right side of a criteria condition that determines when to execute the update.
• On the right side of the field update to calculate and determine the new field value.

Get and Collection Filter Elements

You can use a formula resource on the right side of the criteria condition to specify which records you want in your output while configuring these elements.

Assignment, Create and Action Elements

While these elements don’t have criteria conditions in them, they can utilize formula resources to compute field and the parameter values.

Example:

You might use a Formula Resource like: {!TodayPlusSeven} = {!$Flow.CurrentDate} + 7 And then assign this value to the due date of a task or close date of an opportunity.

Benefits of Using Formula Resources in Criteria

Using Formula Resources gives you an advantage when you want to use them again in your flow. Reusability would be the biggest advantage of using a formula resource in a criteria condition rather than building the logic in the element line by line.

One could also argue that formula resources can handle complex logic better in certain situations.

Formula Resource or Multi-line Criteria Conditions

Instead of inserting formula resources in criteria for decisions and updates, you should consider building multi-line conditions combined with AND and OR operators. Using formula resources may have negative performance impact on larger flows with many of them. They are computed several times throughout the execution of the flow, which may be more resource draining than building a multi-line criteria condition inside one element.

If you are not worried about performance in your particular case, or this is not a record-triggered flow, then this may not be a concern.

There are several other advantages of building criteria conditions directly inside an element like a decision:

• Readability: Even if you find a very descriptive name for your formula resource and add a description to it, it becomes a black box that you have to open, in order to understand the logic.
• Maintenance: Unless you use the same formula resource more than once in your flow, clicking through multiple formula resources to understand and update the logic can be more difficult than doing the same inside the element.
• Ease of debug: Your debug log can show more detail about how your criteria condition logic evaluates the data compared to the a formula resource that just returns a boolean value (true/false).

Pro Tip 1: When setting up formula resources, prefer returning a value to compare to, rather than a boolean value if your use case supports this. Example: Prefer returning the difference of days between today and the record created date, rather than setting up an IsRecent boolean formula resource that returns true when the record was created in the last seven days.

Pro Tip 2: If you need a not contains criteria condition and only see contains, you can go to custom logic in most cases and add a NOT() around the criteria condition with the contains clause.

Conclusion

Use formula resources only when you definitely need them. Consider setting up multi-line conditions combined with AND and OR operators instead. Name them clearly and add comments and descriptions.

If your use case requires setting up complex formula resources, break down the formula in smaller pieces and test them separately, before you put the whole thing together. Sometimes it may make sense to create a formula field on the object temporarily, when building a complex formula. This way, you can see the result of the computation immediately on multiple records (leverage list views).

Remember that the comment syntax used for Apex also works in formula resources. You can use it to add comments to complex formulas, like this: /* Example: This comment can wrap over multiple lines. */.

This post is part of our Best Series collection. Read the other posts HERE.

Explore related content:

How To Build Flex and Field Generation Prompt Templates in the Prompt Builder

Start Autolaunched Flow Approvals From A Button

Can You Start With a Loop Inside Your Schedule-Triggered Flow?

Display Product and Price Book Entry Fields in the Same Flow Data Table

A Comparative Look at Flow Decision Elements in Salesforce

#Apex #BestPractices #FormulaResources #LowCode #NoCode #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials

Can You Loop Inside a Loop?

A loop in programming is a control structure that repeatedly executes a block of code or low code as long as a specified condition is met. It enables programmers to automate repetitive tasks, iterate over data structures (like collections, arrays, or lists), and efficiently handle scenarios where the same operation needs to be performed multiple times. Using loops, developers can build cleaner, more concise code and reduce redundancy.

The simplest and most common way of looping in coding is through the use of a for loop. A for loop allows you to execute a block of code a specific number of times by defining an initialization, a condition, and an increment/decrement operation in a single, compact structure. It is widely used in many programming languages due to its clarity and versatility, especially when the number of iterations is known in advance.

Image source: https://admin.salesforce.com/blog/2022/automate-this-how-to-use-loops-in-flow

Loops within Loops (Nested Loops)

Loops within loops, often referred to as nested loops, are not inherently antipatterns, but they can become problematic depending on the context and scale of the data being processed. Nested loops are perfectly valid when dealing with scenarios that naturally require a hierarchy of iterations. However, they can lead to performance issues, especially when both loops iterate over large collections, resulting in increased complexity. This can significantly slow down the execution of code or low code.

Are Nested Loops an Antipattern?

When there are more efficient and optimized alternatives available, then nested loops become an antipattern. Additionally, deeply nested loops can reduce code readability and maintainability, making it harder for other developers (or even your future self) to understand and modify the code.

The key is to assess whether the nested loop is the simplest and most efficient approach for the given problem. If not, it’s worth exploring alternative strategies to improve performance and code quality.

Loops in Flow

Loop have limited functionality in flows: You have to loop over a collection, and you can only determine whether you want to loop first to last or the other way around. Salesforce flow lacks all the other sophisticated ways you can loop in code.

For loop can be achieved in Salesforce flow by leveraging the assignment and decision elements. A loop element cannot be used to create a for loop. To loop 5 times in Salesforce flow you do the following:

1. Create a counter variable CounterVar.
2. Increment the counter variable value by one using an assignment element functionality. Configure the assignment element to show CounterVar Add 1.
3. Add a decision element to check whether the CounterVar equals 5. If not send to flow back to step 2.

Collections

In Salesforce Flow, collections are a type of variable that can store multiple values of the same data type, allowing you to manage and process lists or groups of records efficiently within a flow. Collections are particularly useful when you need to handle bulk data operations, such as looping through records, performing actions on multiple items, or passing data between flow elements, flows and code.

Salesforce flow also lacks the capability of building and processing complex collections compared to the the functionality in code.

When are Nested Loops Necessary?

When you are processing related records, nested loops may be necessary. Before you take that route, please consider more efficient alternatives by evaluation the following factors:

• When modifying multiple records with the same field values, you don’t need to loop and build a collection to be used outside your loop. One single update element with criteria can do this for you. Example: Close all cases matching a specific criteria (e.g. under Account Acme).
• When checking whether a specific junction object record exits before creating a new one, consider leveraging the collection filter element. This setup seemingly results in a nested loop because the collection filter outputs a collection. However, internal loop iterates at most a single time, and therefore does not present a performance concern.
• When checking whether a record exists before creating it, consider leveraging the check matching record functionality in the create element. This functionality currently does not work for junction object records, and the matching record criteria builder is limited. Read Create by Checking a Matching Record in Flow to learn more about this functionality.
• Check whether you can leverage the transform element to save one of the loops in your nested loop setup. Read 6 Things You Can Do With The Transform Element to learn more about this topic.
• When comparing two collections and finding common and uncommon members, consider invocable Apex actions on UnofficialSF. These actions leverage the enhanced collection functionality in code to bring efficiency to your flow.

Optimize Collections and Avoid Nested Loop Pitfalls

In addition, consider using the assignment element for getting count of members in the collection, and the transform element for getting sum of number field values in a collection. While these are not tips related directly to nested loops, they may save you one loop within your nested loop configuration.

Finally, remember that the get element now supports a maximum number of records to get. This number can be set to any number between 1 and 2,000. Also note that the collection sort will take the same parameter while sorting the records, allowing the collection to be trimmed to a smaller member count.

If you considered all the alternatives, you can still use nested loops. Avoiding DMLs and SOQLs (Gets) inside your loops, you could avoid most of the governor execution limits. Your biggest risk is going to be hitting the dreaded Apex CPU limit error.

Conclusion

When designing Salesforce Flows, it is important to avoid nested loops whenever possible to maintain efficiency and prevent performance issues, especially when dealing with large datasets. Nested loops can significantly increase the number of iterations, leading to potential governor limit exceptions and reduced performance in the Salesforce environment. Instead, consider using collection processing techniques, such as using formulas, assignment elements, or collection filters. Additionally, leverage Apex Actions for complex logic. There are scenarios where nested loops are absolutely necessary, such as when processing multi-level data structures or implementing hierarchical logic. In such cases, it is crucial to minimize the loop size by applying filters beforehand and optimizing the logic within the loop. This ensures the flow remains scalable and maintainable. Ultimately, the key is to strike a balance between avoiding unnecessary complexity and using nested loops judiciously when the business logic demands it.

Explore related content:

Salesforce Flow Best Practices

Can You Use DML or SOQL Inside the Loop?

How The Transform Element Saves You Loops

Start Element Formulas

#Antipattern #ForLoop #Loops #NestedLoops #SaleforceAdmins #Salesforce #SalesforceDevelopers