I'm hoping that someone might be able to give me a bit of guidance on an issue I have been presented with as part of project I'm currently working on.
Basic scenario is that for each person in SFDC, there may be multiple records with the same email address. These can not be de-duplicated because each relates to a specific trial signup or upgrading to paid plan. ie. if someone signed up for a free trial and then upgrades to a paid plan you would end if with three records: 1) the original lead from Marketo/sales person; 2) the trial signup; 3) the paid plan.
This obviosuly presents a problem when you come from the Marketo side and need a single record to sync data between, because if source data etc is synced to the original record, it won't be associated with final record when person becomes a customer - but you can't merge the records because for internal reasons they need to be kept seperate. I'm going to need to delve into why it has to work this way, but I guess my two questions at this point are:
I'd recommend using a custom sync rule, which will need to be implemented by a support engineer.
This sync rule will allow the duplicates in SFDC to continue to exist for the reasons you mentioned, but will not create duplicates in Marketo. With a little bit of planning and dev of a few workflow rules in SFDC, you can define a "primary" record which will have the "Sync with Marketo" flag set to true. Once implemented, here's how your above scenario will play out...
1. Lead is created in Marketo 2. Lead is synced to SFDC 3. Workflow rule in SFDC will automatically set Sync with Marketo to True so that it will continue to be a synced record 4. Lead signs up for a trial, dup record is created in SFDC only with Sync with Marketo set to False 5. Lead signs up for the paid plan, dup record is created in SFDC only with Sync with Marketo set to False 6. Custom fields such as "Signed up for Trial" and "Signed up for Paid Plan" on synced record will be set to True for segmentation purposes in Marketo.
This is clearly a very high level overview and there are more considerations, but if you're up for the challenge, you can make it work.
An alternative is to create a custom object tied to the record that handles the trial and paid user issues. This will require programming.
I don't get why it matters to have several records. I have seen something similar before, but it didn't seem necessary had there been some thought about how to manage the interaction with your product.