19

I'm very surprised that there is no support for dev/staging environments with Marketing Cloud Connect. That is, there is no ability to build and test the integration of a Sales Cloud Sandbox org, then promote the integration to use a production org.

I feel very uncomfortable and embarrased in advising my clients that they need to integrate Marketing Cloud Connect directly to their Sales Cloud Production org. There are so many reasons why this is a bad idea. One major risk is during Journey development and testing (when using a Salesforce Entry Event). Naturally, you want to inject test records and validate the decision split activity behaviour and email branches. But of course, when you do so, Leads/Contacts are going to also be injected (that meet the Entry criteria).

While there is a Marketing Cloud Sandbox Edition available which provides the ability to build campaigns and data in a non-production environment, where Salesforce Support can copy a production account configuration to a Sandbox Edition, it's limiting in that:

  1. Only Data Extension schemas are copied, not data
  2. Only Email Studio is supported (not Journey Builder, Audience Builder, and others)
  3. Marketing Cloud Connect configuration cannot be migrated

There are only three options that I am aware of, neither of which are ideal. I'm thinking that surely this has to be a common requirment, particularly in financial services and large enterprises.

There are really only three options for building and testing Sales Cloud integration with Marketing Cloud that I can think of, which are:

Option 1: Configure Connector to Sandbox, Switch to Production

In this scenario, Marketing Cloud Connect would be configured to use a Sandbox org, then the Managed Package would be reconfigured to integrate with the Production org once development has been completed.

Pros

  1. Enables the business to validate Journeys, Automations and Data using a production-like environment and test with sample data, before go-live.

Cons

  1. All Journey Data Events and Journey Decision Split Activities would need to be removed and rebuilt
  2. Existing Synchronized Data Extensions would need to be deleted and re-created for the Production Environment
  3. Support intervention will be required to de-couple the Contact model and cardinal relationships in the Sales and Service Cloud Attribute Group after re-configuration
  4. All Journeys, Campaigns and Automations would need to be re-tested when the Managed Package is re-configured to production

Option 2: Enable multi-org configuration

In this scenario, a separate Sandbox Business Unit would be used to connect the Business Unit to a separate sandbox org, while the production Business Unit would be connected to a Sales Cloud Production Org.

Pros

  1. Enables the business to validate Journeys, Automations and Data using a production-like environment before and after go-live

Cons

  1. Enabling multi-org configurations alters the underlying architecture of the account and cannot be reversed at a later date
  2. All Journeys would need to be rebuilt in the Production Business Unit
  3. All Automations would need to be rebuilt in the Production Business Unit
  4. Synchronized Data Exensions would need to be rebuilt in the Production Business Unit
  5. All Journeys, Campaigns and Automations would need to be re-tested in the Production Business Unit

Option 3: Integrate to Sales Cloud Production Environment

In this scenario, Marketing Cloud Connect is configured to the Sales Cloud Production Environment.

Pros

  1. No re-testing would be required after Journey and Automation development
  2. No duplication of effort

Cons

  1. Introduces risk: emails could be sent to Customers from Journeys and Automations during development

I typically use option 3 and add Exclusion Scripts to all:

  1. Email sends initiated from Email Studio
  2. Email sends initiated from Automation Studio
  3. Triggered Sends
  4. Journey Builder Send Email Activities

My Exclusion Script looks like this:

Domain(emailaddr)!='mycompany.com'

This ensures that only emails are sent to my client (in this case, with the domain 'mycompany.com'). But obviously there is room for error, where you need to be careful to ensure that all emails use this Exclusion Script, then remove it later.

I'm curious to learn what others consider 'best practice' when integrating Marketing Cloud Connect?

  • Hey @eliot, what do you mean by "Support intervention will be required to de-couple the Contact model and cardinal relationships in the Sales and Service Cloud Attribute Group after re-configuration". We are about to cut-over to CRM production and may be impacted by this. – Vic Sep 2 '18 at 12:18
  • Hello @Vic, when you create Synchronized DEs, cardinal relationships are created in a Sales and Service Cloud Attribute Group which are mapped based on a predetermined priority. Also, Contact Alternate Identifiers are used (for User Id, Lead Id and Contact Id) to create the relationship to the Contact Record. I've observed that when switching to a different Sales Cloud org, the internal Alternate Key Store (used to manage these relationships) isn't magically reset and requires intervention. – Eliot Harper Sep 2 '18 at 21:50
  • @EliotHarper with regards to option 3, I'm looking to go down that path but wanted to clarify for existing journeys and automation on data extensions there would be no impact on changes required. context it would be a connection to CRM and our SFMC account has no other existing connections all data is currently imported via SFTP – Luke Harrison Feb 7 at 0:35
  • 1
    Hi @LukeHarrison, yes that's correct. You would not need to change anything, except remove the Exclusion Script from emails. – Eliot Harper Feb 10 at 14:08
6

Thanks for sharing your point of view on this problem. I am confronted with the same discussions and the client's faces always turn white when I explain to them the different options.

To be honest I push them to option 3. I explain that SFMC is not Salesforce and the concept of a sandbox is still blurry. I generally don't get pushback. If I do, I scope for option 1 then when they see the difference in prices, they go for option 3 (with a little prayer and a lot of trusts - never got any issue with option 3 and I did a lot of implementations).

I feel that we have difficult conversations because of a product gap. SFMC should be better at managing sandbox and prod.

  • Thanks Jeremy. I raised this with Salesforce and they agree that option 3 is the best solution. It's still far from ideal though. – Eliot Harper Sep 4 '18 at 1:44
  • Hi Eliot, thank you for the detailed explanation. I have a better understanding of the options now. I have one doubt though, options 1 and 3 are both single org connectors and the difference lies in the usage only, right, i.e., the way we are configuring it. In option 1, we connect(to sandbox)->disconnect(from sandbox)->connect(to prod) while in option 3, we connect Marketing cloud directly with Prod in the first go. Is my understanding correct? – Krati Garg Mar 4 at 7:01

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.