Our client wants to connect his Service Cloud with Marketing Cloud. When connecting Salesforce CRM with Marketing Cloud, the Contact ID becomes the SubscriberKey/ContactKey in SFMC.

The client also has another external source of contacts (contacts from his eCommerce site) that he wants to add in SFMC. These contacts may not have any Contact ID.

What should be the ContactKey then in SFMC? Is it OK to "mix" 2 kinds of ID as ContactKey in SFMC?

Is it possible to choose another ID as Contact Key in SFMC than the Contact ID once the MC Connect is installed?


This is far beyond a pure development matter. Essentially, the question is, is it ok to have multiple Identity Providers ("mixed model") or should you go for one Identity Provider, which is Sales / Service Cloud - and which will use the SFID as Id. I will try my best at a concise starting point.

Can you use a mixed model with multiple Identity Providers? Yes, but it's not simple. Complexity is typically in data stewardship and maintenance. It would be best to find a system that can give an ID to all records.

Should this system be SF, and assign an SFID to everyone? Yes, but it's not simple. Complexity is typically in initial setup.

Going for an SFID is the "canonical" solution, as all kinds of cross-cloud experiences (service,commerce, marketing) leverage the Service Cloud ID. Other system could fill the same role, but some MC COnnect features might not be compatible to this.

There is a strong tendency towards using an SFID consistently as this is what the SF products "assume" in order to work together. So new features might require this setup. Customizing your own way could really become unsustainable, as it could lead to even more customization to keep up with new developments on the platform.

Avoid Duplicates

The main problem with separate ID providers (or none at all) is that you will have potential duplicate records in your architecture, which leads to multiple issues:

  • a) no single view on a person = more complex processes than necessary, imagine: Deletions (GDPR), confusion in customer service (orders are assigned to another ID...). This can have a long, long tail.

  • b) Each contact record in SFMC counts against your Marketing Cloud contractual contact record limit. So Duplicates => (unnecessary) cost. Refer to your contract for finding out the applicable limit.

Automatic Key assignment by SF infrastructure

You simply cannot get MC Connect to use another SubscriberKey than the Lead / contact / user ID. This alone is problem enough, as these could be a potential three IDs per person, typically two with Lead and Contact ID.

You also have to understand that duplicates of "shop id" and an SFSC Contact ID can occur just by using Standard MC Connect capabilities: As soon as someone is injected into a cross-cloud journey, the Contact / Lead / user ID is used as a Contact record. Even if Marketing Cloud already knows the same person already with a "Shop ID".

So even if an external system can be found to provide IDs for all records - just be clear that you might still get SFID contacts just by using a journey listening to an SF object! You could of course decide to not leverage Salesforce Objects as data sources in Journeys at all, but that might be a hard sell.

You might be more flexible in trying to get records from a shop or third party system into Service Cloud before they reach Marketing Cloud - but this isn't necessarily easy either:

Potential roadblocks for getting an SFID for external data

Integrating e.g. shop data into Sales / Service Cloud is of course out of the scope for your typical Marketing Cloud project. It also might meet some resistance as current processes could be in place that are not in line with having all those eCommerce addresses as Contacts in the Sales Cloud / Service Cloud. Typically you have to start with "what is the definition of a contact?", which is quite fundamental in an SF org.

The list of problems continues with (stupid, and definitely solvable) technicalities like for example missing lastnames in the shop data (a required field in Sales Cloud), and ends with contractual limits on storage - which can have cost implications, as well as service cloud performance considerations - you could easily reach "large data volume" territory with a large b2c setup and all records having to be in Service Cloud for the ID.

Ways to make a mixed model work

If you DO anyway go for a mixed model, you need to understand what you are in for:

Separate keys mean separately kept History, Permissions / Preferences and targeting information. You need a means to transfer all of this information (or define that is OK to ignore it) from one record to the next at a certain lifecycle step (like, first order... whatever), meaning that you have to think of some sort of "conversion" process from a "shop" to a "real" Contact. Such a process should end with the deletion of the now obsolete "shop id" contact in Marketing Cloud to reduce contact count via the Contact Deletion Framework.

Either / or Decisioning

Decide for ONE approach. Going "mixed" first, then later deciding to reverse and try to assign an SF ID to every person is a rather painful process if your system is already in operation. It is called "Subscriber Key migration" and involves SF Support costs and a potential sending downtime of maybe a week or so. So it is definitely not an iterative step but a conceptual cut. MAKE SURE YOUR DECISION FOR OR AGAINST A MIXED MODEL IS UNDERSTOOD WITH ITS IMPLICATIONS and get a written signoff.

Hope this gets you started. If you asked me for a bottom line recommendation, it would be: If at all possible, push for an SFID for all records. I'd rather go through some conceptual & political pain early, than risk never-ending maintenance pain later.

But basically, solving your question is a full-time job profile. :D

  • Excellent answer right there Jonas, don't even know why it didn't get any upvotes. I think it might be interesting to post it as a LinkedIn article.. Feb 17 '20 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.