Salesforce Marketing Cloud (SFMC) is a multi-channel marketing platform offering from  Salesforce.com. With industry-leading email, mobile, web, social media and predictive intelligent marketing solutions, the SFMC platform has become an important tool for many companies that are focusing on 1:1 personalized digital marketing.  

Unlike core Salesforce platforms that feature easy-to-use sandbox functionality, SFMC does not come with a development/testing environment – Business Units are considered production environments by default. With this in mind, it’s important to focus on Development, Testing and Deployment strategies when using the Marketing Cloud. If you are having long discussions with your clients or stakeholders on how different these strategies need to be structured in the Marketing Cloud compared to its partner tools like Sales Cloud, Service Cloud and other core Salesforce platforms, this article can help you navigate the solutions available for ensuring that your SFMC setup is developed and tested effectively. 

Here are three creative options that follow best practice implementation methodology in terms of Development, Testing and Deployment in the Marketing Cloud.

‍1. Use Test/Development Folders Within One Business Unit

Setting up test folders in one Business Unit is the most cost effective approach. It’s also the most convenient and efficient way from a deployment and navigation perspective. This option requires less effort compared to other strategies, but it is important to take your organization’s data security into consideration when choosing this approach.

Some tips:

1. Create folders and versions for each respective staging environment. For example, if your infrastructure has four staging environments (DEV, QA, UAT and PROD), follow the same structure in SFMC.

2. Make sure that test data follows certain naming conventions for each folder to avoid mixing up test data. For example, if the subscriber key is an account number, you could have DEV123, QA123, UAT123, 123 (PROD) or any nomenclature or format that works for your organization. If the subscriber key is an email address, ensure to have a designated email address for testing of each environment. 

Pros

–   Copying and promoting components is easier and faster without switching to other Business Units (saves 30-50% of time in terms of deployment). 

–  This option is cost effective as there is no need to purchase another Business Unit for Test/Development environments.   

Cons

–   There is a higher chance of user error since production data is accessible and can be accidentally used for testing.

–  There is heavy API consumption, especially when integrating to multiple systems. All integrations will need to be replicated for each folder and can affect performance.

2. Use a Separate Business Unit Within One Enterprise Account

While not as cost effective as the first approach – especially if your organization has multiple production Business Units – this method separates your test data on a data extension level, which is ideal from a data security perspective. SFMC’s Package Manager can also help this type of implementation, but does have certain limitations as outlined  below.

Some tips:

1. Even with a separate Business Unit, create  folders and versions for each respective staging environment. For example, if your infrastructure has four staging environments (DEV, QA, UAT and PROD) follow the same structure in SFMC.

2. Create a naming convention for the subscriber key (if not an email address). For example, if the subscriber key is an account number, you will have DEV123, QA123, UAT123, 123 (PROD) or any nomenclature or format that works for your organization. If the subscriber key is an email address, make sure  to have a designated email address for testing of each environment.

3. Use Package Manager to copy components from one Business Unit to another. 

Pros

–   Development/testing components are separated from the production Business Unit, meaning there is a  low risk of mixing up production emails, contents, integrations and data.

–   The risk of sending test emails to production data is low, as production data is not accessible during test emails and development.

–   This does not impact production Business Unit’s API consumption or domain if development/testing Business Units have dedicated IP/domains. 

Cons

–   Additional cost if the current license has no available provisioned Business Unit (one Business Unit can cost thousands of dollars).

–   Package Manager does not support all components when moving from one Business Unit to another, so  manual work is still needed.

3. Separate Enterprise Account

This is the most expensive approach but provides the greatest separation for your production data. It not only separates data on a data extension level but from the All Subscribers List as well, which is the main contact database of SFMC. Package Manager is still applicable and helpful in terms of deployment, but it may require from scratch account configuration and setup, which can be time-consuming.

Some tips:

1. Check if your clients or stakeholders are willing to purchase a separate account. The cost may be worth it for large organizations.

2.    Go through all the platforms’ setup activities made in the production business unit. Designate a new domain for development and testing.

3. Use Package Manager for deployment.

Pros

–   This option does not share a contact model with the production Business Unit, so test data is not combined with production data into one All Subscribers List.

Cons

–   A new enterprise account has a significant cost.

–  This requires a duplicative effort of setting up the platform.

–   Package Manager does not support all components when moving from one Business Unit to another. Manual work is still needed.  

Why These Strategies Matter 

Here are the main reasons why it’s important to develop a Development, Testing and Production strategy that fits the needs of your organization: 

–  Test and Production Data Management: It is very important to segregate test data from production data to avoid mixing up your data, which can create confusion especially when sending test communications to production data.

–  Proper versioning: An effective development/testing environment is essential to a successful IT implementation. Developers/testers should have a dedicated environment where they can test new features, enhance existing components and perform proper versioning.

–  Seamless Communication: Avoids sending test communications to production data, which can lead to a communications disaster for your brand.

–   Designated Testing: Structures the data in an All Subscribers List or a contact model by setting up test data nomenclature or designating an email address for development/testing only. 

Choose a strategy that works for you and the organization based on infrastructure and security guidelines. Until SFMC develops a standalone testing environment, it’s important for SFMC architects to develop a successful strategy for development and testing. By using one of the three options above, you will help your organization develop a well-tested production environment.