This content has been marked as final. Show 6 replies
I'm fairly certain that there is no way to prevent Marketo's automatic de-duplication of new leads via form fill, SOAP or Munchkin API call or list import into Marketo. The only way to get duplicate leads into Marketo is to create them first in SFDC vial import into SFDC or via a web-to-lead form.
Having multiple duplicate leads can create all sorts of problems. Is your auto-convert to a Contact occuring in Salesforce? I ask because the Marketo convert to a Contact also creates an Account (unless there is an existing Account with an exact name match) and it creates an Opportunity, which may not be desirable. Why don't you use a different trigger for the conversion in Salesforce (e.g. a checkbox field that is set to "true" when they fill out the Marketo form)?
I strongly agree wth Elliott: duplicates are not desirable in first place.
There is one subtle detail I would like to comment: SOAP can be set to enable duplicates.
The method syncMultipleLeads allows to turn off the dedup feature with this function call. If dedupEnabled is set to true and no other unique identifier is given (foreignSysPersonId or Marketo lead Id), then the lead record will be de-duplicated using the email address. Keep in mind, passing in 'false' will create duplicates within Marketo.
The feature is available. Elliott has a valid point you should consider very carefully before allowing duplicates anywhere, not just Marketo.
@bgomes - is the method you suggest form specific or would it turn off de-duping for the entire system?
I'd love to turn off de-duping on event registration forms where one person registers multiple people and uses the same email address for everyone.
The method works for any source sending data via SOAP API's syncMultipleLeads.
An individual form could collect data, save to a temporary file or database and then use SOAP to send all registrations at once.
Thanks for the replies everyone.
While the specific situation where we have duplicate leads (one lead, one contact) is still in play, we've decided to experiment with the idea of converting the original lead with the new information in the form.
It turns out our process actually had bugs in the trigger code (your suggestion of a custom field is exactly how we designate these special leads, but the wrong field was being checked by the trigger code).