To Multi-Org, or not to Multi-Org, that is the approach

Deciding 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.

* Post updated on 2021 December 8th.

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 the hierarchy 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

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

Multi-Org Strategy is the strategy where a customer has multiple Salesforce Orgs. Data and applications are split into 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

PROS	CONS
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 the respective BU’s context. Therefore, tracking and contact data works more intuitively compared to one org setup.	“All Subscriber” will be storing all user’s 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.
Connect each of your Marketing Cloud business units to a different Salesforce org	It will be also critical to define and manage one Custom Profile and Preference Center per BU carefully
Get direct access to synchronized data instead of having to build SQL queries and a data extension sharing strategy.	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.
	May increase your Contact count more than you intended. If you connect multiple orgs and synchronize Salesforce objects with Marketing Cloud, your Contact counts will go up.

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 license, 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 breaking 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.

Org Strategy Decision Guide

	Requirement/Use Case	Single Org	Multi Org	Weight
R-001	Are there any regulatory, compliance,security or Sharing requirements?			Critical
R-002	Single Business with global process standard and global data access ( unification)			High
R-003	Independent but similar business units ( Replication)			High
R-004	Unique Business units with a need to know each others transactions (Coordination)			High
R-005	Independent business units with different customers and expertise ( Diversification) ( aka autonomy)			High
R-006	Are there any Customer 360 or global case management or global business reporting requirements?			Medium
R-007	Have you reached the hard governor limits of what you can do in a single org?*1			Critical
R-008	Will you be using Chatter?			Low
R-009	Are you prepared to deal with the complexity of having multiple LOBs (Lines of Business)/Regions inside a single Org?			High
R-010	How many Lines of Business/Regions/Locations can you support? ( time to market)			Low
R-011	How much change can you effectively manage in a single org? ( predictability of delivery)			Low
R-0112	Large number of Integrations with backend systems/ master data			Med
R-013	Are you willing to pay for the overhead of multiple orgs? ( cost)			Low
R-014	Who will modify your org(s) & who will maintain your org(s)? ( multiple distributed dev and Support team)			Low