Best Practices for Testing Marketing Cloud Connect Integration

Question

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?

Answer 1

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.

Answer 2

the best option would be have two seperate business units, one connects with sales cloud prod, one connects with Sales sandbox.

however, this requires an enterprise license for marketing cloud connect, otherwise, you will only have a single connection to one salesforce instance.

Answer 3

[update 2020]

To my knowledge and experience, regarding point 1 "Switch to Production" cons and considering the support a required intervention.

In order to clarify, I had a look at the official documentation that states that it is a normal process to disconnect Sandbox Instances. No need for support intervention will be needed as a step to be completed.

Please refer to the section.

“Disconnect Your Synchronized Data Sources Connection for Sandbox Instances Only” https://help.salesforce.com/articleView?id=mc_co_implement_synchronized_data_sources_best_practices.htm&type=5