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