I was wondering if someone here could help me have a bit more clarity over a behavior I'm seeing when executing flows in SF. I need to call a subflow from a record-triggered flow to execute some actions, however I'm seeing it's behaving differently when I do so vs when I run the actions directly from the record-triggered flow.

Here's a simplification of what I'm trying to achieve:

My flow is first searching for a Case record with the following subject "Testing098", then it gets to a decision where if the previous Get records element Is Null = true, it determines that the Case record does not exist and creates it in the next step, however if it does exist, the flow ends.

I've tried this same flow on both a record-triggered flow and a record-triggered flow that calls an autolaunched flow with my logic

enter image description here

enter image description here

enter image description here

If I edit a case both flows get triggered and create the "Testing098" Case just fine. The differences however, start when I edit more than one case in bulk.

If I edit 3 cases in bulk the Recordtriggered-only flow creates only one "Testing098" Case. But the Recordtriggered plus autolaunched flows create three "Testing098" Cases.

My question here is, how SF executes this kind of flows?, I understand it tries to bulkify the elements that allow to do so. Is it that in the recordtriggered-only flow SF understands that there's a decision dependent on the get records element and doesn't bulkify that part?, and in the Recordtriggered plus autolaunched doesn't see the sub-flow contents and just bulkifies it for the three Case updates?

  • 1
    I'm surprised by your assertion that the Record-triggered flow creates only one Testing098 because the Get Records element is bulkified and only 1 SOQL query is executed which would not find the Testing098. Are you sure the bulk edit of 3 records is a true single transaction and not three transactions (as the 2nd and 3rd would see that Testing098 already existed
    – cropredy
    Dec 20, 2023 at 19:18
  • Hi cropredy! Yes, pretty sure, I used the same approach for both tests, an updat operation using salesforce inspector with the same batch size. Will make a second test later today but I’m pretty sure I did it the same way in both cases Dec 20, 2023 at 21:03
  • Hi again cropredy. I have to apologize, I'm not sure why last time I got that behavior but you're right, in both cases SF bulkifies the records update in the same way. My only guess of what could have happened the first time I tried is that I modified an automation I already have to include this, I didn't use the simplification shown in my question, maybe that had something to do with how SF handled the operation. I'm ansering my own question with my finidings, thanks! Dec 20, 2023 at 22:31
  • I'm investigating on a way of avoiding this. Will answer myself once I find how to do so, to include it here, but any suggestions you may have will be very welcome! Dec 20, 2023 at 22:43

1 Answer 1


Your assertion that the Record-triggered flow creates only one Testing098 Case is not correct.

  • The Record-triggered flow Get Records element Find Case record testing098 is bulkified per the Flow Bulkification doc
  • Hence, your test must have inadvertently submitted not 1 transaction with 3 records, but three transactions. Thus, transaction 2 would discover that transaction 1 had created Testing098

Now, your general problem is how to keep multiple interviews in the same transaction from creating three Testing098

  • Since each Flow Interview runs in "parallel", the interviews don't talk to each other nor are aware of what the other is doing.
  • The common solution to this is to delegate the record creation to an invocable Apex.

The invocable Apex is bulkified and would receive a collection argument of dimension equal to the number of flow interviews in the transaction that reached that Apex action Flow element.

Thus, the invocable can examine using collection operators and for loops whether the request to build a Case record is duplicated. The invocable can then de-duplicate the request and create only unique Cases.

Just remember that if the invocable returns values back to the Flow that there has to be 1 result element per request element with result[i] corresponding to request[i]

You must log in to answer this question.

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