1

I am running into a strange problem with a flow that has lead me to wonder if I am not understanding how flow interviews work on bulk inserts and I am not able to find any documentation that answers this question -

Currently I have a flow built on Custom_Object__c that fires on insert. As part of this flow, it tries to look and see if there is any leads that exist in the system with an email that matches the one provided on the custom object, if it does find one, it updates it, and if it does not, it creates a new lead.

The problem that I am running into is when the system takes in a bulk update of custom object records, if more than one record exists with the same email, I am getting a new lead for every email.

The expected behavior would be that when we have two records with the same email being inserted, one lead would be inserted on the first run of the flow in that interview, and then in the next run of the flow in the interview it should find the lead we inserted in a previous run and update that lead instead of insert new.

Since this is not the case, I am wondering if this is an issue where the DML for the first run does not actually take place during the first run but is instead held until the end of the full transaction? Or if there might be another explanation for this behavior.

If this is whats happening, is there a work around for this or would this be a scenario that needs to be handled in an apex trigger instead?

2
  • 1
    When you say 'if more than one record exists with the same email', are you referring to more than one record in the batch that is being processed? If that's the case, then unfortunately this might be due to the way that Flow Bulkification in Transactions works. From my understanding there isn't a way to interrogate the other Flow interviews that are taking place to unfortunately an Apex Trigger may be the way to go as you have access to all the records being processed. Commented Aug 10, 2023 at 21:06
  • Yeah that is exactly what I mean. It does seem that what you're saying is correct as that is exactly the outcomes that I am seeing. I have moved this over to a trigger and it seems to resolve the issue. Commented Aug 14, 2023 at 19:27

1 Answer 1

1

One Flow Interview has no idea what another Flow Interview is doing. They run logically in parallel.

Hence

  • Flow Interview [0] for email E queries for Leads with Email = E and decides a Lead needs to be inserted
  • Flow Interview [1] for email E queries for Leads with Email = E and decides a Lead needs to be inserted

When both Interviews reach the Create Record element, Flow bulkifies the transaction and does a single DML Insert with a list of two leads; each with the same Email = E - this is what you observed.

The best way you can avoid this is to use an invocable Apex action. Invocable Apex actions are bulkified - it will be called once with a list of Leads to do something with. List element [0] is from Flow Interview [0], list element[1] is from Flow Interview [1], etc.

The invocable Apex can de-duplicate the requests by pivoting on the Lead.Email field across the requests and do only a single insert for Email E

Note:

The invocable Apex conceptually has to decide what to do if it receives two Leads, each with Email E but different values for Company or LastName. Which one is the "winner"? You might need heuristics or just go with the first one.

You must log in to answer this question.

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