2

I have a question about bulkifying scheduled flows. When you create one you have two options. Use a get element to grab the records you want or set an object & conditions. I've found the documentation confusing around which is the preferred method.

My understanding is that when you specify an object the flow will create an individual flow interview for each record. There is a limit of 250,000 flow interviews/24HRs along with all the normal limits. But if you have a sufficiently complex flow and expect it to pull in a large volume of records this is preferable as it prevents you from hitting nodes visited/DML limits.

In the case of using a Get statement, you don't have to worry about the flow interview limit, but you do need to worry about nodes visited/DML limits. Oh! And you get to work with collections!

This makes me think that specifying an object is better for bulkification, I know there are other limits around date/time fields you can use in the criteria that might lead to one or the other, but from a pure bulkification best practices perspective specifying an object is correct?

Can anyone confirm my understanding or explain to me the correct way of thinking?

Additionally - in this help doc. There is the follow:

The maximum number of schedule-triggered flow interviews per 24 hours is 250,000, or the number of user licenses in your org multiplied by 200, whichever is greater. One interview is created for each record retrieved by the schedule-triggered flow’s query.If you specify an object so that the flow runs for a batch of records, then set the time, frequency, and record conditions to avoid reaching this limit. You can use debug logs to check how many records a schedule-triggered flow runs on. Track the number of records with the FLOW_START_SCHEDULED_RECORDS event. If your org reaches the limit, Salesforce sends a flow error email.

This seems to indicate that specifying an object is the preferred method, but it's really confusing to me. Also I'm not sure what it means by the "schedule-triggered flow's query"

Thanks in advance!

2 Answers 2

2

I won't speak to the "best practices" piece of your question, but will try to answer the part about "Can anyone confirm my understanding or explain to me the correct way of thinking?". NOTE: This is written in layperson's terms to help ground the technical in understandable language. Don't crucify me for my metaphors.

You have two options with schedule-triggered flows:

  1. Do NOT specify a target object in your Start element
  2. DO specify a target object in your Start element

For option 1:

  • You have setup an auto-launched flow to be triggered based on the schedule you set in your Start element. So build your flow as you would if it were an auto-launched flow with no entry criteria specified (read: You will need to use a Get Records element in your flow).

For option 2:

  • Your Start element not only determines the time/when it will run, but it also acts as a Get Records element with a PREBUILT LOOP element. So, for example, if your entry criteria results in 12 records being queried, each record will be "looped" through the flow (i.e. 12 separate flow interviews). Build this flow as if your entire flow is a giant Loop.

If you want to test this out to see what I mean, setup two flows, one for Option 1 and one for Option 2, and add a "Wait for Amount of Time" element at the end of each one set to 5 minutes. After each flow runs, go to the "Time-Based Workflow" in Setup and look at the paused flow interview list. Option 1 flow will show 1 paused flow interview, whereas Option 2 will show a paused interview for each record that entered the flow. NOTE: Make sure you do this in a sandbox and setup your criteria to query just a handful of records.

1

I got an answer to this from Mikey Brown on the Salesforce community. See Below:

Hey Thomas, I agree with your understanding. As a best practice, I agree that specifying the object up front in the entry conditions of the scheduled flow is the way to go, especially for bulkfication. I know there can be some confusion where admins will set a very generic entry criteria for the scheduled flow, and then use a get records inside the scheduled flow to drilldown to the records they want, but in my opinion, this can degrade performance as it's executing this get records for every iteration of the initial collection of records that met the criteria. It's usually more effective to have your entry criteria essentially be your Get Records element so that everything you need to gather upfront is already collected. I liken using a Get Records inside a Scheduled Flow similar to using a Get Records inside a Flow Loop. It's not recommended because you can easily hit governor limits (although sometimes it is needed for complex scenarios)

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .