[This post was originally published on 9th July 2020. It has been updated on 8th April 2022.]
Marketers work within Salesforce Marketing Cloud as a part of teams and sub-teams. These teams can be divided into various categories depending on the enterprise or the specific use cases. The marketing teams can be categorized based on factors like region, markets, organizational hierarchy, or any particular setup. This categorization helps the organization and its marketing teams recreate an ideal working environment within the Salesforce marketing cloud.
This functionality is facilitated within Marketing Cloud through a feature known as Business Units. Salesforce Marketing Cloud business units help organize and control access to the information with various marketing and IT teams. Information content can be in the form of multiple artifacts, templates, and subscriber data and settings. Marketing Cloud Business Units can control all of these.
For example, a global company with regional offices can be adapted within Business Units. You can do this by creating Salesforce Business Units representing each regional office. It means there can be multiple Business Units with a single Salesforce marketing org. This is beneficial as the marketing and IT team users working within the regional office only get to access the information and artifacts relevant to their specific region. It is also helpful in simplifying things for the users and stopping access to information between cross-regional teams. Marketing and IT teams working under the same Business Unit will have full/partial access to the information depending upon the configurations done based on the business rules.
Key aspects of the Business Unit that you must know before we move forward:
- Tenants: Tenant is a top-level enterprise account purchased by the company or organization along with multiple Business Units.
There are four types of Tenants:
- Enterprise 2.0
- Enterprise 1.0
- Core
- Agency
Currently, all the new Marketing Cloud orgs are provisioned with Enterprise 2.0 Tenants, and hence, can host multiple Salesforce Business Units within the Tenant.
- Account name: This is the initial name set at the time of account provisioning and is usually the company name.
- MID: This is a unique identification number assigned to each Business Unit and child Business unit. So your account might have multiple MIDs representing each Business Unit.
Business Units are created in Marketing Cloud in the form of a hierarchy. The top Business Unit is called the Parent Business Unit, and Sub Business Units are called child Business Units. The Parent Business Unit and Child Business Unit hierarchy is illustrated in the below image:
There are no definitive sets of business rules guiding the creation of the hierarchy of Business Units within the Marketing cloud. Still, there are a few guidance points based on organizational structure and data requirements to decide Business Unit models within an Account. These guidelines are as follows:
- Are there separate brands or divisions or regions that require their marketing teams to work in separate Business Units as per specific data needs?
- Is there a requirement to model the marketing cloud’s exact organizational structure in the form of Business Units?
- Is there a requirement for a separate branding for each division of marketing teams?
- Is there a set of common assets that require sharing between various marketing teams?
- Is there a requirement for a separate space for testing and UAT activities?
The use case for Business Units
A global retail company named X is implementing Marketing Cloud within their marketing departments across the globe. Their Marketing teams are based in different regions worldwide – North America, Europe, EMEA, and APAC.
Based on the requirements, below are a few considerations for implementing the Business Unit’s hierarchy within the Salesforce Marketing Cloud of the company X:
- Parent and child Business Units can model the regional divisions of the Marketing teams, i.e., Child Business Units can be North America, EMEA, APAC, Europe.
- The Parent Business Unit can serve as the headquarter for company X and can be reserved for the administrative purposes handled at the headquarters’ level. These admin activities include providing access to the users to their specific regional Child Business Units, storing the company branded templates in the Parent Business Units’ shared folders and the common subscriber data in shared Data extensions.
- Set up approval processes for requirements such as making any changes in the email templates. Since the emails need to follow strict branding guidelines, any changes made to the templates should require approvals from the relevant authorities.
- Each Child Business Unit should be a self-sufficient unit with its subscriber data and email template, although based on the Parent Business Unit’s branding guidelines. For example, the North American Business unit will have its separate campaign and subscriber data for the North American marketing teams.
Below is the pictorial representation of the Parent Business Units, which represent the headquarters and admin capabilities. Each child Business unit is represented by a regional team, namely North America, APAC, Europe, and EMEA. All the Child Business Units are fully self-sufficient companies within themselves but use the Parent Business team guidelines.
Best practices of Marketing Cloud Business Unit
Some of the best practices that should be followed as a part of creating/using Business Units are as follows:
- Parent Business Units should be considered for admin purposes and not used for any specific purposes apart from admin activities. The Parent Business Unit can also be used to model the organization’s headquarters.
- Admin activities include all the shared data that needs to be accessed by child BU across the organization.
- Data includes branded HTML email templates, shared subscribe data, etc.
- One of the Child Business Units should be created as a testing Business Unit so that any new email template, automation activity, or Journey can be tested in the Test Business Unit before being released to the real child Business Units.
- User permission should be enabled in a way to provide or restrict access as per the Business Unit concept, i.e., Admin users should have access to all the Business Units starting from the Parent Business Units. Users specific to each Business Unit should have access to their own Business Unit’s information, artifacts, features, and not other Business Unit’s information.
- The subscriber data that needs to be shared by the Parent Business Unit with its child Business Units should be placed inside the Shared Data Extension folders inside Email Studio. This will be helpful to reuse the information across the Business units without copying it manually.
- The HTML mail templates that need to be shared by the Parent Business Unit with their Child Business Units should be placed inside the Shared folder inside Email Studio. This will be helpful to reuse the information across the Business Units.
- The journey should be tested in the testing Business Unit for its correctness and validation. Finally, after it is ready to be used by Marketing teams, it should be transferred to the relevant Child Business unit via the Deployment Manager feature.
- Approvals should be used by the Child Business Unit to obtain any required change from the guidelines set by the Parent Business Unit. Suppose the Child Business Unit wants to make some changes or create HTML email templates from scratch. The approval mechanism should be configured to take approvals from the relevant authority.
- The calendar on the Marketing Cloud homepage should be used to view and publish the campaign schedule for all the Business Unit users. This helps to view the similar campaigns run by various teams and users on other Child Business Units.
- Separate Business Units also efficiently manage the unsubscribe process, as the subscriber unsubscribes from specific Business Units and not all the Business Units.
Wrapping It Up
Business Units are an integral part of the Marketing Cloud org as they form a key pillar of the structure. The above use case guidelines as well as marketing cloud business unit best practices should help you when designing the Business Unit structure in the beginning. You need to be super careful while doing so, as any failure might create issues later in the life cycle. Also, you must follow the best practices while designing the Business Units, as they help maximize the Salesforce Marketing Cloud benefits.
For a more detailed understanding of Business Units, you can refer to the Salesforce help documentation.