Decide whether to go with a Multi-Org or Single-Org approach requires a deep analysis and time. With this post, I am trying to provide the key elements to understand how each approach works, but it doesn’t mean that has to be strictly followed and applicable in your business case.
During the AS-IS and TO-BE analysis phase of a Marketing Cloud implementation, one of the key things to decide is the architecture of the Business Units (BU). A Business Unit is just an environment, a way to separate data and control the information can (or cannot) be shared with the other business units. It works with a hierarchical structure, meaning that we will always have the parent business unit already setup in heirarchy above the child business units.
This scenario only applies when Marketing Cloud is going to be integrated with Sales Cloud or Service Cloud. If not, a Single-Org solution (when there is a single source of truth) with different business units, if needed, should be enough.
A non-trivial solution
Following the previous point, imagine we need to connect Marketing Cloud and Sales Cloud, but we are managing data from different teams/countries that, due to company data policies, cannot be shared. If this information is also managed independently in Sales Cloud, then we need to consider each set of data as a different source of truth in Marketing Cloud (Multi-Org).
It means that different ‘Marketing Cloud Connectors’ need to be configured with all the technical considerations to keep in mind: synchronized data extensions, all subscriber list management, salesforce data entry source in journey builder, custom profile center may be needed…
Single-Org Strategy is composed of just one Salesforce Org and all the business processes (how complex and disparate they may be) are implemented within that Org.
Multi-Org Strategy is the strategy where a customer has multiple Salesforce Orgs. Data and applications are split in different Orgs depending upon factors like different business units, countries or product lines. We can talk about two main different approaches here:
- Multiple business units connected to multiple orgs.
- Multiple business units connected to a single org.
In the documentation, you can also find some examples of different Multi-Org scenarios.
Multi-Org Enablement Implications
|Use Dev Salesforce Environment as test data provider for testing purposes||Once is enabled is not reversible|
|Avoid to test with production data||Each BU needs to be configured separately|
|Differentiate the branding of each brand (if applies)||Current campaigns and content has to be replicated from the old system (Single-Org) to Multi-Org|
|The Shared Items folder structure can be used to share content between Business Units||“All Contacts” will contain contacts from all Business Units|
|Journey Builder will function within respective BU’s context. Therefore, tracking and contact data works more intuitively compared to one org setup.||“All Subscriber” will be storing all users actions, no matter which Business Unit is being the action delivered, so “All Subscriber” Lists from the Business Units will be storing Production and Testing Data.|
|It will be also critical to define and manage one Custom Profile and Preference Center per BU carefully|
|You will need a custom preference center and you will need to consider carefully all the subscribe/unsubscribe flows, to get a clear implementation about what systems must be updated and when.|
In the end, we can think that Multi-Org is a way to manage different Marketing Cloud accounts within the same one. Considering the main pros and cons described in the table below (and the main one: the cost of the licence, budget and expected revenue), we can have an overview to consider which approach is the appropriate one.
Multi-Org for ‘Sandbox’ purposes?
Based on my experience, having a Sandbox environment in Marketing Cloud, is one of the key reasons why customers think about a Multi-Org approach.
It is a fact (and a pity) that in Marketing Cloud everything is in ‘Production’, and the only way of having a playground reducing the risk of sending massive emails or break something is using one single Business Units with the right user permissions.
But, what about the testing data? The easiest way is to create our own set of test data in different Data Extensions accordingly to the scenario we will recreate with the production data:
- Test email personalization
- Test roles and permissions
- Test new developments
- Do some demos
- Design Journeys and test the Sales Cloud and Service Cloud activities
Especially regarding the last point, we need to easily identify what is test data so we will be able to delete it once we don’t need it anymore.
From my point of view, and considering the main Cons of a Multi-Org approach, the purpose of having a ‘Sandbox’ is not a reason to switch to Multi-Org, especially when there are feasible workarounds that can accomplish the requirements of testing.