This is related to another post I had created earlier today. I have a couple of questions on lead partitions and dupe rules.
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.
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 | First Name | Last Name | |
1 | Osman | Erzinclioglu | |
2 | Osman | Erzinclioglu | |
3 | 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.
First Name | Last Name | |
John | Smith | |
Jane | Smith | |
Jack | Smythe | |
Jack | Rickles | |
Nancy | Proops | |
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.
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.
Thanks, Hussam AlMukhtar! That certainly helps clarify some of the potential implications of going this route.