De-duplicating Flow

Flow Builder for de-duplicating

I recently had the opportunity to use the new Flow Builder for a customer project where the requirement was to check each new Lead added to the system, flag it as a duplicate if either email, telephone, or mobile number had been entered against any existing Lead or Contact and then link the record to the possible duplicate.

This requirement could have been met partially with a series of Duplicate Rules or an Apex Trigger but this particular customer was using the Professional Edition of Salesforce which does not allow the development of Apex (just the installation of Apex via Managed Packages) so this seemed like a good opportunity to try out the new Flow Builder.

Launching the Flow

I decided that to launch the flow from Process Builder whenever someone tried to save a new record. That would mean the Process Builder would need to pass variable information through to the flow.

Previously, launching Flows from Process Builder required lots of input/output variables to be created and then mapped between the 2 tools. 

Now, you can save an entire SObject as a variable when passing from Process Builder to Flow – hurrah! 

However, the SObject isn’t available in the debug option of Flow Designer so I also kept the previous pattern of saving the record ID against variable ParentID to help with testing.


So, testing the Flow without firing it from Process Builder and passing through an Object record was a little tricky. 

When testing the flow for the first time, I would get an error message if I pressed debug.

I eventually tracked this down to the fact that Debug tool expects a variable called ParentID to be set, either manually when you launch debug or somewhere within the Flow.

So, the first thing I added to my flow was:

  • First decision point – checking whether the Flow has ParentID set or not. If not, load it up.

I added this step into the Flow to check whether that variable was populated (as it would be when launched from Process Builder) and if not (when launched via Debug) to populate the variable with a lookup.

No equivalent of OR statements in the Get Records step



After moving through the first decision step in the flow I got to a GetRecord step. For this I needed to find another Lead where:

The telephone number matches, OR the email matches, OR the address matches another record

Now, weirdly I could not see any way to put this conditional logic into GetRecord so I ended up linking a bunch of them together to cover all variations. I reached out to the Salesforce community to see if I was missing something obvious but it seems to be a gap at the moment – please consider adding this feature Salesforce! 🙂


After daisy-chaining the GetRecords together, I then had to have matching Decision steps linking them together. I tried reusing them initially but because the customer needed that OR function, the logic really had to travel along its own path.


The Gotcha

So far all good. Then, when debugging I kept getting a really strange error message.

In my Get Record steps I had selected the setting ‘When no records are returned, set specified variables to null.’

However, when running the flow I would keep getting an ‘unhandled fault’ message. This also happened when using debug. 


The eventual solution? I found that in the decision step after the Get Records action I had to check whether the overall SOjbect variable was null or not rather than checking a particular field.

So {foundLead} Is Null worked

But {} Is Null caused an error

I can see the logic behind the error but I don’t understand why the setting to default to Null doesn’t work with it. We got there in the end though.

The Finished Flow

So, a few more loops, decisions and Get Records and here’s the final version!