Testing Environment Strategies in Marketing Cloud

Many Salesforce Marketing Cloud users look to create a testing environment much like what exists with Sales Cloud CRM. With the Salesforce CRM (a.k.a. Sales Cloud) each account typically comes with an option to create a separate sandbox, where development can occur outside of the production Sales Cloud environment. However, Marketing Cloud sandboxes are limited, rarely encountered and deploying Change Sets is not a feature that exists within Marketing Cloud. However, testing is still possible! In this blog, I will share with you the different strategies for testing within Salesforce Marketing Cloud that are available.  I’ll start by discussing the options if your Marketing Cloud account is not integrated with Sales Cloud, but I will also add in some of the caveats to each option when an account is integrated with Sales Cloud. 

NOTE: If you are using Marketing Cloud without a Sales Cloud integration, your testing setup is going to be limited to a few different options (starting with simplest to more complex) 

Do I even need a Testing Environment? 

This is a good question, dear reader, and one you should examine thoroughly before proceeding too deep into the sandbox conversation. Why would you need a separate sandbox testing environment and is it right for you? If you only need to test email rendering and dynamic content – you may not need a separate test environment (and you could very easily use the first recommendation below if you need any type of pseudo test environment). If you do need to keep your test data and processes separate from your production data and processes, then you will want to consider a sandbox environment. 

Let’s look at a few of these strategies:

Duplicate components within the same business unit 

One method of creating test components in the Marketing Cloud is to simply create duplicates of anything that you want to test. For example, if you have a data extension named “Master Data Extension”, you would create a separate data extension named “Master Data Extension TESTING”. This data extension would only contain the records that you’d want to have utilized for testing purposes. Similarly, you would create separate emails, Cloud Pages, send definitions, automations, journeys, etc. – all as duplicates of the “production” versions.  

Pros: 

1. Cost-effective: no additional business unit or Marketing Cloud instance required to purchase or configure

2. You can pick and choose whether to create duplicate components depending on your needs

Cons: 

1. Not at all a true sandbox or testing environment

2. All items you want to test would require duplicate TESTING components, causing extra work and an additional quantity of items within the account

3. When moving the test code to production (i.e. an email, content area, query or Cloud Page) any references to the TESTING version would need to be manually updated to point to the production version. This makes it very easy for a mistake to occur by not referencing the proper component

4. All test records will live in All Subscribers / All Contacts

If you have a Sales Cloud integration with Marketing Cloud, this method will only allow you to work from production Sales Cloud data. Creating tests will require filters (within your Sales Cloud report, your query, data filter, journey entry event, etc.)  to ensure you only pull in the appropriate test records. This is definitely a riskier method as it increases your chances of accidentally testing with production data.  

 

Using this method with the same business unit will also mean that you cannot integrate your Marketing Cloud business unit with your Sales Cloud sandbox while still being connected to your Sales Cloud production account (this is because with the single org connector, you can only connect one Marketing Cloud account to one Sales Cloud account). 

Utilize a separate business unit in your Enterprise 2.0 account 

One simple way to test your emails, journeys, and automations is to utilize a separate business unit within your Marketing Cloud account. This separate business unit will essentially act as your testing ground or sandbox. 

Pros: 

• Creates a separate area away from the production business unit(s) to test automations, journeys, emails, queries, etc.  
• Most likely a cost affordable option compared to a new Marketing Cloud instance 
• The new Deployment Manager app provided by Salesforce will assist in copying a limited number of items from one business unit to another

Cons: 

• You will most likely need to spend additional money to utilize this separate business unit (and best practice will require that you actually purchase 3 business units – a parent, then 2 children, each representing the production and sandbox) 
• Duplicate effort is required to create the same configuration in the test business unit that exists in the production business unit 
• Any subscriber data you add to this testing business unit will enter into All Subscribers / All Contacts 

• Deployment Manager is fairly limited and does not typically copy all components from one business unit to another. It is not a Change Set deployment tool

If you have a Sales Cloud integration with Marketing Cloud, you can turn on the multi-org connector option on your Marketing Cloud account so you can connect your Marketing Cloud sandbox business unit to a separate Sales Cloud sandbox. This will provide a direct connection between Marketing Cloud’s sandbox to Sales Cloud’s sandbox, as well as Marketing Cloud production to Sales Cloud production. This is much closer to a real testing environment. However, multi-org is an all or nothing decision and there are multiple considerations you should review before proceeding, including that once multi-org is enabled it cannot be disabled. One downside to enabling multi-org is that you may actually have a use case where most of your Marketing Cloud business units need to connect to just one Sales Cloud CRM and take advantage of sharing from a parent business unit. This is easiest to manage without multi org.