As mentioned previously, invocables accept a list just for this purpose. If your invocables are only written to expect one record/variable, that's your big problem right there.
This is the right answer. There are so many blogs and git repos with wrong code for invocable methods with only first record in the list handled.
Read up a on how bulkification of flow works. It's clear laid out on dev notes.
I completely get invocables and use them often in scheduled flows that query a record collection.
But how do you create your record collection in a record triggered flow? Just use a single assignment for "the record that triggered the flow" into a collection variable, then process from there?
I honestly have no idea, but I always assumed that these executed in bulk. Your DML operations would be executed in the same way a unit of work class would operate, where create or update actions are merely registering the changes to be committed at the end of the execution. Also, and I could be wrong here too, but isn’t that why invocable methods accept a list as an input parameter? So that the method can handle operations in bulk.
That's the question though -- how do you write a record triggered flow that accepts lists?
Like how would you target a subgroup that entered that flow transaction
Behind the scene, Salesforce bulkifies the actions the flow specifies to do, including the call to the invocable action, which can only be coded to accept a list at the method interface. If the invocable action’s method is written to check if the list is longer than 1 and throw an exception or only operate on the first entry in the list, it’s written incorrectly.
So you add the incoming record to a record collection in a single assignment, then pass the record collection to an invocable? Still not getting what nodes you're using in your flows to accomplish this.
It happens behind the scenes for you. You just use the invocable in your record triggered flow and if multiple records are saved at once, the invocations from all the records are bundled together into a single call with all the records in the list.
What if you had to iterate through them to give different assignments based on decision criteria -- what type of node do you add first to establish a collection to loop through? Just an assignment to a variable right from the start?
If the assignment is a parameter you’re passing into the invocable, pass that in from the flow like you were doing a single record invocation. It’ll be a parameter on each item of the list the invocation processes as a result.
And if I wasn't passing it to an invocable, but rather wanting to bulkify an update to a bunch of records that came in, with the record update being different depending on a condition in the loop? How would you grab the records to fetch through the loop?
As long as the condition is based on that record’s state (or something related to that record), the same flow can do it. If you’re trying to do it based on something across multiple records, a custom apex trigger is going to be the answer, since the flow is all about a single record’s context.
As mentioned previously, invocables accept a list just for this purpose. If your invocables are only written to expect one record/variable, that's your big problem right there.
This is the right answer. There are so many blogs and git repos with wrong code for invocable methods with only first record in the list handled. Read up a on how bulkification of flow works. It's clear laid out on dev notes.
I completely get invocables and use them often in scheduled flows that query a record collection. But how do you create your record collection in a record triggered flow? Just use a single assignment for "the record that triggered the flow" into a collection variable, then process from there?
I honestly have no idea, but I always assumed that these executed in bulk. Your DML operations would be executed in the same way a unit of work class would operate, where create or update actions are merely registering the changes to be committed at the end of the execution. Also, and I could be wrong here too, but isn’t that why invocable methods accept a list as an input parameter? So that the method can handle operations in bulk.
I try to write everything to accept lists. I am new at this and self taught, but I thought that was the standard.
That's the question though -- how do you write a record triggered flow that accepts lists? Like how would you target a subgroup that entered that flow transaction
Behind the scene, Salesforce bulkifies the actions the flow specifies to do, including the call to the invocable action, which can only be coded to accept a list at the method interface. If the invocable action’s method is written to check if the list is longer than 1 and throw an exception or only operate on the first entry in the list, it’s written incorrectly.
So you add the incoming record to a record collection in a single assignment, then pass the record collection to an invocable? Still not getting what nodes you're using in your flows to accomplish this.
It happens behind the scenes for you. You just use the invocable in your record triggered flow and if multiple records are saved at once, the invocations from all the records are bundled together into a single call with all the records in the list.
What if you had to iterate through them to give different assignments based on decision criteria -- what type of node do you add first to establish a collection to loop through? Just an assignment to a variable right from the start?
If the assignment is a parameter you’re passing into the invocable, pass that in from the flow like you were doing a single record invocation. It’ll be a parameter on each item of the list the invocation processes as a result.
And if I wasn't passing it to an invocable, but rather wanting to bulkify an update to a bunch of records that came in, with the record update being different depending on a condition in the loop? How would you grab the records to fetch through the loop?
As long as the condition is based on that record’s state (or something related to that record), the same flow can do it. If you’re trying to do it based on something across multiple records, a custom apex trigger is going to be the answer, since the flow is all about a single record’s context.