About 6 months ago, we created workspaces for CAN, EMEA, and APAC... but we didn't create corresponding lead partitions. Instead we've just been using the default lead partition with all workspaces.
Now, we want to add lead partitions corresponding to each regional workspace, but I'm not sure what to do about existing programs in APAC workspace for example that have members that live in the Default lead partition. What happens when I change the APAC workspace lead partition from Default to APAC?
Is the approach that I need to create smart campaigns to move APAC program members to the APAC lead partition?
In general, I don't want to screw anything up. Any help would be appreciated.
Dan Stevens, your thoughts? Thanks!
If you use the existing WS and only let it see ONE LP, then those Programs will no longer "see" the leads in other Partitions. Your counts on old programs won't change I believe, however, if you try to refresh the data, it will def throw an error or lower the counts.
Recommend reading further
Yes, you would need to manually push APAC Leads to the APAC Partition once the Partitions are live. You will need a processor to handle incoming leads to change partitions.
Jonathan - If I understand correctly, you have the default workspace/partition and then three additional workspaces (CAN, EMEA and APAC) - for a total of four workspaces? You may be in good shape, as long as the members of your programs exist within the countries aligned to each region. For example, let's say you have a program in your APAC workspace with members from Japan, Singapore and Malaysia (and no one outside of APAC). You then create three additional lead partitions with a 1:1 mapping of workspace to lead partition (e.g., APAC workspace can only access the APAC lead partition). Next, create a batch routing campaign (for the initial routing of all leads in your DB and then a similar trigger campaign for ongoing routing (new leads enter your DB). Everyone that's now in the APAC partition should still be members of the programs in the APAC WS.
BTW, here's a sample of the routing campaigns (we have country partitions, so our routing is more complex):
And then don't forget to setup workspace/partition visibility in Admin:
I would advise to be careful when creating partitions. Two issues come to mind:
I have personally encountered both of these issues and would recommend you address them in cooperation with your regional Marketo users before you implement partitions.
You bring up some valid points, Pavel - and when using multiple partitions/workspaces, it must be a well-planned out effort where all of these "gotchas" may occur. And yes, it can get messy if you don't have a clean environment (e.g., lots of duplicate records). Fortunately, Jonathan's dealing with 3 custom workspaces/partitions - not 23 like we have. It will be much easier to manage. For global organizations like ours - where we have very strict data privacy and accessibility policies/compliance requirements, we have no choice but to setup our instance like we did. And it does minimize risk for ensuring that someone can't accidentally email the entire database, for example.
Regarding point #1, this can be minimized if a solid data governance strategy is followed. For example, ensuring that every person has a "country" value so that the central routing rules apply to everyone. In other words, no person will just reside in the default partition and not in one of the regional partitions.
Regarding point #2, we actually have a trigger campaigns that listen for when this happens and send out an alert to our ops team to correct it (when someone registers for an event or submits a contact-us form on our website - and Marketo uses the record in our purposeful duplicates partition instead of the correct record in the country partition):
It's also worth pointing out that issues like those that can exist in #2 are a result of Marketo's inconsistency way of determining which record is the active record among duplicates: If duplicate leads are an issue, be aware of how Marketo determines which lead is active
Thank you so much for this insight that you posted a few months back. Do you mind explaining how you set up and use your "Duplicate Contacts" partition? We're running into the issue of leads not triggering because they are a part of a different partition. Thanks!
Hi Jonathan - check out my reply in this post a while back (Re: Lead Process Updating ) to better understand our "now retired" purposeful duplicate process. We're no longer doing it this way as it created so many duplicates and the activities were not being collected centrally (using a "single record of truth" approach).
The functionality of our new sync environment is the ability to work a CONTACT over and over again (since we often market/sell into existing accounts). We run this temporary duplicate workflow on the CRM side (not Marketo). When a CONTACT – which exists in CRM – becomes marketing-qualified/sales-ready again, we create a new LEAD record in CRM from the PARENT CONTACT – and this is the record that is worked by Marketing and Sales (prior to this, we used to create a duplicate lead in Marketo, sync it to CRM as a lead record – and there was never a connection to a parent contact record). The new/temporary lead is never synced to Marketo (to prevent duplicates in Marketo).
Instead, any changes/progression made on that lead is written back to the parent CONTACT record to custom/temp fields – and it’s this data that Marketo sees and uses to update the “lead” in Marketo (and send out the appropriate alerts):
We even have customizations in place to swap the MSI iframe on the lead record with the MSI data from the parent contact record so that all of the rich insights are available on the working lead record.