Lead duplication when created from Salesforce and Web API

[Anonymous]

Leads are created on our Marketo from two sources - Salesforce.com and Web API. In an ideal situation, if a lead exists on Marketo and if another source tries to create the lead using the same email address, it should sync data to existing profile instead of creating a new duplicate lead profile with same email address. We have accumulated thousands of such duplicates and they continue to add up every day.

Here is a visual representation of this problem:

I'd love to know if the community has any ideas and best practices that can help us resolve this problem.

[SanfordWhiteman]

That image is in your private GDocs or something... but anyway I think we get the idea!

The main place you should be controlling SFDC-originated duplicates is in SFDC itself. You should be able to tell that an existing SFDC record is synced to Marketo; why aren't you merging into that record to begin with, before exposing the dupe to Marketo?

[Anonymous]

Thanks Sanford. I just corrected the image

We're actually not syncing all Marketo leads to Salesforce as majority of them are end users of our product and we use Marketo for email automation for them. It overlaps and end up with duplicates when these users are also created on Salesforce (maybe a prospect trying our product etc.) and Salesforce syncs them separately or sometimes even the other way round (Salesforce.com creates first, then our product via the Web API).

Thankfully, our Salesforce is free of duplicates but I am trying to get my head around how we can combat the dedup issue when leads are created from two different API sources.

[SanfordWhiteman]

Thankfully, our Salesforce is free of duplicates but I am trying to get my head around how we can combat the dedup issue when leads are created from two different API sources.

When creating leads via the Marketo REST API you can choose your lookup key.

I wasn't talking about syncing all Marketo leads to SFDC -- but Marketo cannot automatically merge a Marketo-side lead with a separate SFDC lead/contact that is suddenly exposed to the sync user.

[Anonymous]

Okay, that would definitely solve half the problem - when leads are created via REST API after SFDC has already created it but if it would still leave us with duplicates when created the other way around.

Let's just say that we are ok with duplicate profiles being created but need to identify them separately so that relevant emails can be sent to the profile with right lead ID. For eg: Demand gen is one partition and End-user engagement is another partition. The experience and journey of a lead in both the cases are completely different. Could Workspaces and People Partition be a potential solution?

Thanks so much!!

[Robb_Barrett]

Resurrecting this old thread.

I recently changed jobs and inherited an instance of Marketo and its challenges.  We have an issue with lead duplication.

First off, we do allow purposeful duplicates in SFDC and Marketo as a way to indicated multiple product interests.  This isn't something I'm going to be able to change.

However, here's my user story: I was asked to look into why we're getting dupes from APIs.  Most of these are quite old so it's really difficult to know what was going on at the time, but I see some records where a person was created in Marketo via SFDC in like 2015.  Then in 2017 it looks like a duplicate (based on email) was created via an API.  I have no clue which API created it, who wrote the API, etc.  

@SanfordWhiteman - if I'm reading what you wrote above correctly, there's a setting or method for writing an API call that will check to see if the record exists prior to upserting, and if that method/call/procedure isn't used correctly the API will default to an insert regardless of whether or not the lead already exists.

[SanfordWhiteman]

Not sure what you're asking.

Are you wondering if there's a way to mess up a Create Lead API call that's a lookup by email, so that it inserts a duplicate (on email) even though it was set to createOrUpdate or updateOnly?  No, there isn't, AFAIK.

But you can certainly mess up when using other lookup keys. For example, a lookup on ID can create a new lead, even though you might have though no matching ID == no action (and indeed the docs suggest no action). And of course you can only use one of the lookup keys in a single call, so there are situations where if you don't run a pure lookup (GET) first, you take the wrong action.