I am currently implementing Marketing Cloud in Agile methodology for one of my clients and I am facing a big challenge regarding the release management in Marketing Cloud.

My client has many deployment environments:

  • 3 levels of testing environment
  • 1 Staging environment
  • 1 Production environment

Marketing Cloud will be integrated with Service Cloud and many systems like Apache Kafka and Tibco.

As for Service Cloud, we have many dev orgs and 1 full sandbox.

To simplify the deployement of Salesforce (Service and Marketing) my client wants to use only the staging environment for sprint development and then push to production at the end of each sprint.

We all know that Marketing Cloud doesn't provide a testing environment unless if I dedicate a Business unit for testing (with a manual commit to production business unit).

The Service Cloud Sandbox will be connected to the staging environment and used during the sprint for developing new user stories.

I wanted to know how you management in general the release management in Marketing Cloud especially with many deployment environment (at least staging and production). How you managed the switch between a Salesforce Sandbox and Prod ? One of the ideas would be to use a Test population in the production environment but I prefer not do this..

1 Answer 1


To be honest, there is no easy answer here. Each option, at present, has inherent benefits and drawbacks. At a high level, you have three options:

  1. Test data in your production environments
  2. Dedicate a BU to test data and manually move configurations
  3. Dedicate BU with Multi-Org Connector enabled (cannot be undone)

The setup that most closely resembles what we are used to with Salesforce Core is the third scenario, but to do this you need to have all configurations within same BU's (i.e. you cannot do a BU per country or per brand, everything should ideally be in the same BU)

The scenario I most typically would opt for is the 1st one, given that operating with test-data from production to production, is the one that will ensure most reliable performance (Same contact builder configuration, same / actual data volumes, and potentially limited functionality overlap).

the hardest part in scenario one can be testing how the various scenarios play out, when it is Salesforce Core that executes journeys.

  • In option 1 how do you prevent Subscriber Keys updating overwriting the production keys? For example in production Key 1234 is assigned to contact Fred Smith however in the test BU 1234 is test test. How do you ensure they dont conflict?
    – AndrewC
    Commented Jul 3, 2017 at 2:21
  • In option one, you would have Fred Smith as a separate record in Production, with a separate record Id, so they would never have the same record Id (i.e. never that same keys). In option two, you would import test data into the test BU - again, you should be operating from a test data set, so separate keys. In my opinion, it should never be possible for test keys to overlap with production keys - regardless of what environment they operate in. Commented Jul 3, 2017 at 7:19
  • Thanks Kenneth for sharing all the options available. I think we will choose option 3. In this configuration we will have two indentical BUs, one for Prod and one for Test. The 1st one will be connected to the Prod Environnement (Service Cloud + Kafka + other systems) and the 2nd one will be connected to the Pre Prod Environment (Service Cloud Sandbox + Kafka in Pre-Prod + other systems in Pre Prod). Can you please confirm that there are no functionnal limitations when activating multi-orgs in MC ? I believe that in a previous version of MC Connect, Journey Builder was disabled with Multi-org.
    – zeljazouli
    Commented Jul 3, 2017 at 11:46
  • We will also configure a job in Talend to purge Test records using the API everytime the Sandbox is refreshed in Service Cloud and synchronize with All Subscribers List.
    – zeljazouli
    Commented Jul 3, 2017 at 11:49
  • Multi-org doesn't introduce limitations, but, rather consequences in how the platform behaves. There is a list, Will dig it Up later today, but One thing to note - i believe your synchronized DE's Will have different names. In One BU, it Will be Contact_Salesforce, in the other it Will br Contact_Salesforce1 (2) Commented Jul 3, 2017 at 11:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .