This is related to another post I had created earlier today. I have a couple of questions on lead partitions and dupe rules.Can dupe rules be specific to a partition, or are they applied to your entire instance? For instance, if you duplicate leads to another partition based on a dupe rule, can you also apply dupe by first name / last name / foreign lead key rules that are specific to that partition?Can I automatically assign leads who complete a specific form to a specific partition? (So that anyone who completes a specific form is created in a specific partition if they don't yet exist, or as a dupe in that same partition if they do exist.)If you can create dupe rules specific to a partition and assign users to that partition based on which form they complete, what would be the best way to ensure every form submission remains as a separate lead?

A

Anonymous

Question

Clarification: Dupe Rules and Partitions

Forum|Forum|9 years ago
June 1, 2016
1 reply
3685 views

This is related to another post I had created earlier today. I have a couple of questions on lead partitions and dupe rules.

Can dupe rules be specific to a partition, or are they applied to your entire instance? For instance, if you duplicate leads to another partition based on a dupe rule, can you also apply dupe by first name / last name / foreign lead key rules that are specific to that partition?
Can I automatically assign leads who complete a specific form to a specific partition? (So that anyone who completes a specific form is created in a specific partition if they don't yet exist, or as a dupe in that same partition if they do exist.)
If you can create dupe rules specific to a partition and assign users to that partition based on which form they complete, what would be the best way to ensure every form submission remains as a separate lead?

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

Josh_Hill13

Level 10

Deduping by email address is universal unless you ask Marketo Support to modify it. There are no other good options or settings you can use, however.

Yes, you can route any lead you want to a particular partition. I would ensure that your Default rules are replicated as a central Default program in the Marketing Activities. Do not rely on the Admin defaults for partition routing.

Unless you create some special logic outside of Marketo, you cannot do the deduping rules and routing you want.

A

Anonymous

Thanks, Josh Hill!

On our instance, as is my understanding, each Salesforce contact record is synched to a Marketo record which updates from Salesforce using the Salesforce ID and the setup allows for duplicate e-mail addresses.

To clarify, what I'm really wondering is if we can create a second partition tied to a form/forms which allows for duplicate leads that already exist in the main partition but also has additional rules, that apply only to that second partition, that would create additional leads when other data points provided in the field differ. (Like the first name and last name, as an example.)

So that we'd end up with the following:

Main partition which uses Salesforce integration. Records are unique by Salesforce ID.

Salesforce ID	Email	First Name	Last Name
1	A@B.com	Osman	Erzinclioglu
2	A@B.com	Osman	Erzinclioglu
3	B@B.com	Seth	Green

Second (proposed) partition which can only be populated by forms and which generates a unique record if any of these three fields differ from those of existing leads in the partition. Rules for this partition don't apply to the main partition.

Email	First Name	Last Name
A@B.com	John	Smith
A@B.com	Jane	Smith
A@B.com	Jack	Smythe
A@B.com	Jack	Rickles
B@B.com	Nancy	Proops
C@B.com	Susan	Fletcher

What we're trying to do is capture a complete series of data points, as provided by the user through forms, and use those data points for e-mails related to events, allowing for multiple users to share e-mail addresses, while still accurately reflecting the number of registrants in the program, triggering e-mails each time a user registers, and being able to check in those individual users at events, while keeping the records in the main partition intact.

A

Anonymous

This is somewhat similar to what I had to do before. I laid 4 different scenarios and questions that could have happened with my purposeful dups:

A) Lead X exists in Partition A and Partition B. Lead X filled a form on Partition A and updated lead info in that partition ***And is cookied and tied to partition AS***. Lead X comes back again and fills up a form for Partition B. Which Lead info would be updated?

Partition A since that is what they are cookied to.

B) Lead X exists in Partition A only. Lead X filled a form on Partition A and updated lead info in that Partition. Lead X comes back, fills up a form for Partition B, and created Lead X in Partition B. Can we do that?

If Lead Partition ID is used as a de-dupe rule with Email address, yes. The system would do this automatically. Without it no, answer A applies.

C) Lead X exists in Partition A only. Lead X fills up a form on Partition B, and creates a new lead in that partition. Can we do that as well?

Same as B.

D) Lead X exists in Partitions A and B. Lead X was emailed from Partition A and got cookied as such. Lead X was email again from Partition B. Will the cookie change to reflect Partition B?

No, the rule with web cookies is that they do not overwrite. The click would still record on Lead B, however any web activity after the email click would stay with A since that is the already existing cookie.

I contacted support and they setup a custom de-dupe rule for me based on Lead Partition ID. It helped me with B and C scenarios. I imagine it would help you too. Let me know.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded