Adopting Business Units in Marketing Cloud

Salesforce Architects
Salesforce Architects
12 min readJul 29, 2020

--

Business Units in Marketing Cloud are separate work spaces within an organization’s Marketing Cloud account, that allow different team members or departments within the same organization to manage their data and marketing functions independently while enabling sharing of common assets (such as branded templates) with ease.

Business Units are created in a hierarchy. The main Business Unit at the top of the hierarchy is called the Parent Business Unit, and sub Business Units created under this parent are called Child Business Units. These children, in turn, can have their own child nodes and so on.

Marketing Cloud Business Unit Hierarchy

Parent and Child Marketing Cloud Business Unit Hierarchy in a University

From a business and marketing perspective, Business Units are typically created to manage marketing functions of different subdivisions within an organization. For example, let’s consider a large university which has different marketing teams under Recruitment & Admissions, Student Affairs and Advancement. Each of these subdivisions manage different segments of the audience (leads and prospects, students, Alumni, etc.) and may want to organize and manage their marketing teams and data independently. In this case, the parent IT organization managing the University might create 3 different business units for each of these divisions under the common Parent called the University Business Unit.

By adopting Business Units, the University can:

  • Manage the users of each departments under one umbrella Marketing Account
  • Allow all 3 departments to view and manage just the data they need to manage. For example, expose leads and prospective students to Recruitment and Admissions division so that they can take up suitable marketing efforts with that population; similarly, allow Student Affairs division to market to current university students
  • Provision users into each of these business units independently. Business unit-specific custom user roles can be created if need be
  • Allow users to send different kinds of emails [Recruitment emails vs Student lodging emails] from different business units independently. If one marketer is working for both departments, they can be provisioned into both units.
  • Allow users to share common email templates, images and other assets across all business units

Another use case for Marketing Cloud Business units is the need to manage different sub-brands or regional structures under the same brand . This is important not only in the Retail space, but also applicable to certain Higher Education and Nonprofit institutions. For example, a Nonprofit may be an association of multiple organizations which are serving different needs of the society under different brand names in different geographies i.e. a distance learning or continuing education program. In this case, Business Units will help manage the respective marketing teams with better agility and security. Note that there is another added advantage here: adopting business units will allow subscribers to opt out of just that brand or regional entity — instead of the entire organization. Note that the CAN SPAM law mandates that every marketing email should include an option to allow subscribers to unsubscribe with a single click. Business units feature allows greater flexibility in meeting this requirement.

Features of Business Units

Hierarchy

While there is no right or wrong way to establish a Business Unit hierarchy, specific user requirements and data needs for subdivisions across the organization should be assessed to identify the right model. Some of the classic questions to consider are:

  • Are there different brands or divisions that need separate work spaces due to specific data needs or processes?
  • Are there different branding needs across different marketing teams?
  • What are the common assets and data that need to be shared?

These are some of the classic questions to consider. Also, it is good to avoid too many levels or complex hierarchies which are difficult to manage.

Parent and Child Business Units
Child Business Units maintain their own Subscribers, Users, Roles and Email Templates

Separation and Isolation of User Experience

Within each Business Unit, the user experience can be unique and isolated from the user experiences in the other Business Units.

Business Units allow users to manage the following items independently:

  • Subscriber data and associated marketing information**
  • Email templates, images, etc.
  • User roles (Custom roles can be Business unit specific)
  • Sender profiles and Delivery profiles
  • Email reports
  • Folder structure

** Note: The All subscribers table at the parent level maintains a master list of all subscribers across Business units.

Marketing Cloud Connector and Data Sharing

Customers often use Marketing Cloud Connector from Salesforce to synchronize data between the Salesforce Platform (Sales Cloud,Service Cloud, etc.) and Marketing Cloud. This helps them to manage all CRM data in Sales Cloud while executing Marketing Campaigns from Marketing Cloud.

Salesforce to Marketing Cloud Data Sharing
Marketing Cloud Connector links Salesforce Core Platform and Marketing Cloud

When installing and configuring the Marketing Cloud Connector, the Parent Business Unit should/must be the point of integration between Marketing Cloud and Salesforce. By default, the Marketing Cloud Connector brings in all Salesforce CRM Data to the Parent Business Unit and stores it in Synchronized Salesforce Data Extensions. Note that the Marketing Cloud Admin has the option to choose those fields they want to synchronize for a given Object in CRM, but they have only limited filtering options. Once this data is in the Parent, the Parent can then query and share specific sets of data to each Child Business Unit. This sharing would happen via a Shared Data Extension folder. It can be configured so that a given Shared Data Extension folder is only accessible to a particular Child Business Unit so that no other Business unit would have access to this folder and, therefore, the data. This ensures that the data in each Child Business Unit is secure and specific to their specific needs only.

Because the Parent Business Unit has access to all of the data before it is filtered to each Child Business Unit, the Parent Business Unit can be utilized for communications that need to be sent on behalf of the entire organization.

To illustrate this for Higher Ed, the Parent Business Unit–the University–would consume all relevant student data from Salesforce. The Parent University Business Unit could filter and share data for each of the various colleges to be used to send marketing communications to their relevant students. The University Business Unit, however, may be used to send University-wide communications to all students.

Considerations

Dedicated IP / Wrapping Domain

Depending on send volume or use case, one IP Address can be shared across all Business Units of an Organization. With proper monitoring and maintenance, sharing a dedicated IP gives the organization the ability to maintain a positive Sender Reputation while also unifying the branding.

There may be some use cases where a Business Unit may wish to have their own dedicated IP. Typically this occurs if send volumes are upwards of 2.5 million per month. The additional dedicated IP can be utilized, then, when sending different types of email communications, such as Transactional vs. Commercial messaging.

When the customer has opted for Sender Authentication Package or SAP as a part of their initial setup, the entire Organization can share one dedicated wrapping domain across all Business Units. This domain is used to wrap all URLs and images so that they are reflecting the organization brand rather than the default Marketing Cloud brand. For example, ABC University, a higher ed institution, can designate the domain communications.abcuniv.edu as its wrapping domain and all image URLs and links can be wrapped using that URL.

Typically, a single wrapping domain is used across all business units of an organization. However, it is also possible to configure individual wrapping domains for specific business units if necessary. This is especially required for organizations intending to use Business units to manage multiple brands.

Opt Out / Preference Center

Managing opt-outs from emails can be managed either at the Business Unit level or across the entire organization. If managed at the Business Unit level, when a subscriber unsubscribes from all emails, that preference is specific to emails sent from that Business Unit. If managed at the organization level or Enterprise level, when a subscriber unsubscribes from emails, this preference is applicable across all emails from all Business Units.

Each Business Unit can have its own dedicated Preference Center that can house different communication preferences within it. For example, preferences for different types of email content the subscriber would like to receive can be recorded and modified by the subscriber as per their choice. It is also possible for the organization to choose to manage preferences across all Business Units in one place, using Cloud Pages or other custom preference centers. See the note on Cloud Pages later in this article.

Suppression Lists and Exclusion Lists do exist at a Business Unit level, which allows each unit to control who should and who should not be receiving email communications. It is also worth noting that email validity (e.g. Hard and Soft bounces) are tracked at the Parent Business unit level and applied down to all Child Business Units.

Data Sharing / Security

Both data and content can be shared across Business Units within an instance. As mentioned above, data from the Parent Business Unit can be shared to the Child Business Units as required. But data can also be shared across Child Business Units if the use case arises.

The same is true for content as well as assets. Content from one Business Unit can be shared to another Business Unit. This may be the Parent Business Unit creating and managing email templates or logos for each of the Child Business Units or sharing images across two or more Child Business Units.

It is important to note that in terms of sharing, once a user gets access to certain data in a business unit, you cannot limit their visibility. For example, if a user is granted access to subscriber data within the Business Unit, they will have access to all subscriber data within the unit. The same with content; if the user gets access to content, they have access to all of the content. Folders within the Business Unit help to organize and divide data or content, but cannot restrict access for users within the Business Unit.

Cloud Pages

Cloud Pages within Marketing Cloud allow users to build and publish landing pages or microsites. By using content saved within Content Builder, all content across channels stays consistent and easy to manage. As mentioned above Cloud Pages can be used to create, among other things, Custom Preference Centers. In turn, Preference Centers can represent/display data from within Marketing Cloud at the Child or Parent Business Unit level and even pull and update data from a connected Salesforce instance — using AmpScript.

While the content and assets that are used to build the page can be shared, Cloud Pages as built are limited to the Business Unit that they are created in and cannot be shared across different business units.

Brand Representation

In the Introduction, we briefly discussed the context of managing multiple brands using Business Units. Various divisions, departments, or brands under one organization can divide and manage their marketing functions independently using Business Units. Please note that making use of business units is just an important first step in multi-brand marketing management. Subscribers may not realize or connect with these brands, unless the email templates, images and associated content reflect the individual brand identity appropriately.

For example, let’s consider a University which runs three (3) different schools for Engineering, Business and Commerce. It is possible that these schools are marketing and communicating using their own specific branding and messages. The audience [or learners] for each of these brands are quite different; hence the marketing communication, personalization and frequency should be tailored to suit the needs of these brand audiences / segments. It is also possible that a university wants to start a new online school for adult learners under a slightly different brand name with a totally new set of educational experiences. Under such situations, the concept of Business Units can be effectively used to manage multiple communication experiences under one Marketing Cloud account.

The Parent Business Unit typically represents the parent company or university in this situation and each unique brand under that entity can be housed in their own Business Units and marketed independently.

Considerations:

  • If there is a need to manage or control common branding assets, such as email templates or images, that can be done using Content Builder sharing
  • If there is a need to share Subscriber data or other information across different Business Units, the shared folders in data extension can be leveraged
  • Each Business Unit can host its own custom subscription center using the desired branding and templates — so that its subscribers can manage their profiles and subscriptions appropriately
  • Whilst some groups within an institution may see themselves as an entirely different brand that is not always true for the end audience. Consider the experience of your end constituents as well as internal audiences when setting up new Business units.

User Base and Roles

When a user is provisioned in Marketing Cloud, they can receive access to one or more Business Units. However, providing differential access to different sets of users might become very cumbersome and complex to manage.

Considerations:

  • Limit the number of users at the Parent Business Unit to Marketing Cloud Administrators, any team members that need to see Parent Unit level data (such as Central Marketing), and any teams that create content that are shared across all Business Units (such as Brand management)
  • Individual marketers or technical people who work for specific divisions should have restricted access to respective Business Units only. Within that Business Unit, they might be given desired access to various tools and data
  • If an individual, say a marketer, handles more than one division, they can be given access to more than one Business Unit. However, these should be treated as exceptions and should not become a norm.
  • As far as possible, the roles within each of these Business Units need to be standardized. This is especially challenging when the different Business Units represent different entities which have very different organizational structures. Marketing Cloud does allow creating custom roles at every Business Unit level, but this can easily balloon into an Administrative burden if not managed properly. Best practice is to standardize roles across all Business Units supported by a parent entity
  • Note that creating custom roles is a manual process and there is no way to export custom roles from one Business Unit to another. This can be challenging if a Parent has a number of Children and every Child needs custom roles.

Subscriber management

Since Business units could be independently operated by different teams, it is quite possible that the same constituent is being marketed to, from two different Business units. For example, let’s say a University has 2 Business units — One to handle Faculty and Staff and the other to handle Students. It is possible that a student who is also a part time faculty, ends up in both Business units. Another example would be an NGO which is adopting Business units to manage two of its unique brands and a constituent ends up in both, since he / she supports both causes. Following considerations should be taken into account, if such a situation is foreseen:

Considerations:

  • Make sure the Subscriber key used to identify the constituent is consistent across Business Units. If the same constituent is identified using different subscriber keys in different BUs, Marketing Cloud will not be able to recognize them as the same individuals. Note that irrespective of the pockets of individual subscribers maintained at the Business unit level, Marketing cloud maintains a global list of Email Subscribers which is Business unit agnostic.
  • Make sure that the Opt out / subscriber preferences are managed properly. If both business units are using the same global subscription center, then the preferences will be maintained as long as the subscriber key is consistent. If the Opt out preferences are maintained at the individual Business unit level, then those preferences need to be honored accordingly.

_______________________________

(1) The only exception is for multi-org connected Marketing Clouds, i.e. a Marketing Cloud instance linked to multiple instances of Sales/Service Cloud — more information on that can be found here and on our recent “Ask an Architect” series Implementing Marketing Cloud with Multiple Salesforce Orgs

(2) Filter based on a set Boolean field / Filter data from a set date onwards.

Additional Information

Author Bios

Gokul Seshadri

Dr. Gokul Seshadri is a Senior Principal Customer Success Architect at Salesforce.org based in the U.S. He helps higher ed and nonprofit customers to succeed in their multi-channel marketing, digital transformation, and customer 360 initiatives using Salesforce.org Nonprofit Cloud, Education Cloud, Marketing Cloud and other related technologies.

Rebecca Schults Robrahn

Rebecca Schults Robrahn is a Marketing Cloud Consultant with Accenture based in the U.S. Rebecca works with higher ed customers across the country to strategize, implement, and support their Marketing Cloud instance and integrations with other Salesforce technologies.

--

--

Salesforce Architects
Salesforce Architects

We exist to empower, inspire and connect the best folks around: Salesforce Architects.