By Chad Martin

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.

 

If you do not want to proceed with the multi-org option, you will end up with a similar challenge as the first method mentioned above – once you make the connection from production Sales Cloud to production Marketing Cloud – this will be the only connection possible; you will need to be careful when dealing with production data in your Testing business unit.

Purchase a second Marketing Cloud instance or a Sandbox account

Whether you purchase a specific Marketing Cloud sandbox license or an entire new Marketing Cloud license…you will still be purchasing an additional Marketing Cloud license. The sandbox account has limited functionality, so I would recommend discussing an entirely separate Marketing Cloud instance with your Account Executive. This is the best method forward in creating a true Marketing Cloud testing environment that can perform the role of a sandbox.

Pros:

  • The separate instance is the closest thing to a true sandbox environment within the Marketing Cloud
  • Will allow you a test environment that does not encroach at all on your production instance
  • Keeps test subscriber data separate from production subscriber data

Cons:

  • Additional cost for a separate Marketing Cloud instance, which could end up being costly depending on what you have purchased in your production instance and all of the features enabled on the account
  • Requires duplicate effort to configure this second Marketing Cloud instance, including replication of each business unit’s settings and configuration
  • No true Change Set tool and the sandbox cannot be refreshed from production (and production cannot be refreshed from the sandbox), so moving components from one instance to another would require a tool like Salesforce’s Deployment Manager or an API-based tool

If you have a Sales Cloud integration with Marketing Cloud, you will definitely be installing the Connector twice – once for the sandbox to sandbox integration, and once for the production to production integration. However, you will not need to enable multi-org to accomplish this, since you will have two separate Marketing Cloud instances. This is the ideal and best-case scenario for a testing environment within the Marketing Cloud, as it is the closest replication of a sandbox that is possible within the Marketing Cloud. However, you can imagine how much work it might be to maintain a multi-org sandbox and a multi-org production account, so be prepared for the extra work required if your Marketing Cloud enterprise account contains a large number of business units (that need to connect to multiple Sales Cloud instances) in both a sandbox and production environment.

Are there no other options?

You might have also been thinking, ”What if I just set up my Marketing Cloud account to connect to my Sales Cloud Sandbox, do all of my configuration, and then just switch the connection to a production Sales Cloud account once I’m ready to go live?” In most cases, this will not work out well. The items you have configured in the sandbox are specific to the Sales Cloud org that you’ve connected with, so once you break the connection to the Sales Cloud sandbox and then connect to the production version…you essentially need to reconfigure everything you created within the Marketing Cloud (at least to some degree). Again, this depends on how you’ve created and configured your components in the Marketing Cloud, but for the most part, you will have some re-work. Unfortunately, it’s not just as simple as disconnecting from the sandbox, then connecting to production, and everything magically working as you’d hope.

 

You may also enjoy: 

Chad Martin

Chad Martin

Leave a Reply

Your email address will not be published. Required fields are marked *