Understanding the Purposeful Duplicates Concept | Community
Skip to main content
S
SabinMindrut
New Participant
August 12, 2022
Solved

Understanding the Purposeful Duplicates Concept

  • August 12, 2022
  • 3 replies
  • 4691 views

Hi,

 

Is it possible to use the "purposeful duplicate" concept to create duplicate leads in SFDC, but avoid duplicate persons in Marketo?

We need to allow for lead duplication in the CRM to accommodate lead re-qualification.

But having duplicates in Marketo is not an option.

 

Does it make sense to have a bi-directional sync between the SFDC Contacts object and the Marketo Person object, and a uni-direction sync between the Marketo Person object and SFDC Leads object (Marketo to SFDC)?

 

What other approaches are there?

 

Cheers,

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Chris_Willis1

You can set up what's called a "Conditional Sync" if you want to disallow certain records from synching back to Marketo.  This entails creating a boolean/checkbox field in Salesforce (and then allowing it to Sync) and then contacting Marketo Support with a request to set up Conditional Sync using that field.  

 

We do allow what we call "MQL" to requalify.  Sales cycles and timing issues do necessitate that MQLs don't necessarily convert during their original time and need to be renurtured.  This is a best practice, but it does involve educating your sales team.  

3 replies

Colby_Dix
Colby_Dix
New Participant
March 1, 2023

I've been working on this with a client for well over a year, and multiple clients in the past. If you can somehow convince your Sales org to work opportunities instead of Leads, your life will be amazing comparatively. Because then a 1:1 relationship between SFDC/MKTO becomes truly possible.
But we all know that that doesn't happen all that often. It's a brutal slog to work out to be honest. But I've built exactly what you are talking about with bi-directional Contacts and uni-directional Leads.

When a Lead is created for an existing Contact, it includes the SFDC Contact CaseSafe ID and a concatenated (via tokens) field that basically has Product Interest, and MKTO ID. But once it's over the fence, zero sync to MKTO exists based on basic SFDC permissions.


Having fields on the Lead Record that are also mapped to the Contact is how we're able to sorta close the loop. Closed Reason, Closed Date, and that Concatenated Identifier all write to the Contact upon disposition. At least then you eventually know what happened to them.

There is a TON of complexity I'm not getting into here and while this is working, I wouldn't recommend it to anyone on purpose. 🙂

ooooh shiny.
    SanfordWhiteman
    SanfordWhiteman
    New Participant
    August 12, 2022
    Is it possible to use the "purposeful duplicate" concept to create duplicate leads in SFDC, but avoid duplicate persons in Marketo?

    Reemphasizing one part of Chris’s response: it is not possible to have multiple unconverted Salesforce Leads synced to a single Marketo Person.

     

    Additionally, I’d really question the “need” to have multiple leads to accommodate re-qualification. This was a decision, perhaps a bit reckless given technical restrictions. But that’s not the only way to do re-qualification.

      S
      SabinMindrutAuthor
      New Participant
      August 16, 2022

      Thanks Sanford.

      How would you tackle re-qualifications though?

      We've been creating Tasks in the interim, but this is skewing Marketing Attribution.

       

      In our business we can have a person reach MQL, be disqualified by Sales, and re-qualify as MQL after 3 months.

      This should mean there were 2 leads for the same contact. 

       

      Cheers, 

        Chris_Willis1
        Chris_Willis1
        New Participant
        August 12, 2022

        The native sync would not allow for the CRM duplicates to be de-duplicated upon sync.  This is a core rule of the native Marketo to Salesforce Sync.

        The custom API sync with Salesforce, however, does allow a tool like Workato to be used as the integration facilitator, and you can develop a sync rule via the API connectors in Workato to "Upsert" intentional duplicates in Salesforce with a unique person record in Marketo.  One thing that you will want to think about, however, if you choose this approach is to determine how you will sync the Sfdc ID identifier to the person object record, as a Marketo Person can only be associated through the native SFDC type and SFDC ID fields with one Salesforce record.  Perhaps, a custom object could be used to create a 1:many... I haven't attempted this approach but it seems plausible.  

          S
          SabinMindrutAuthor
          New Participant
          August 16, 2022

          Thank you Chris. 

          I would like to keep the native integration, but prevent leads from syncing back to Marketo.

          This would mean having the SFDC ID on the Marketo Person always an SFDC Contact ID.

          Considering that in the SFDC Contact object we only have uniques, we wouldn't have to do any de-duplication mid-way between the systems, right?

           

          Do you allow MQLs to re-qualify? How would you tackle re-qualification for a B2B company with very large buyer journeys?

           

          Cheers,

          Chris_Willis1
          Chris_Willis1Accepted solution
          New Participant
          April 6, 2023

          You can set up what's called a "Conditional Sync" if you want to disallow certain records from synching back to Marketo.  This entails creating a boolean/checkbox field in Salesforce (and then allowing it to Sync) and then contacting Marketo Support with a request to set up Conditional Sync using that field.  

           

          We do allow what we call "MQL" to requalify.  Sales cycles and timing issues do necessitate that MQLs don't necessarily convert during their original time and need to be renurtured.  This is a best practice, but it does involve educating your sales team.  

          Terms & ConditionsAccessibility statement

          Loading footer...