In essence, CIJ’s approach to business units is crafted to enhance marketing effectiveness, providing marketing departments with the freedom and resources to engage with all contacts within the organization. This supports the creation of targeted marketing campaigns, free from the confines of internal data access policies, contributing significantly to the organization’s growth and success.
Business Units in Dynamics 365
Enterprises often use Business Units to control data access and user permissions based on their organizational structure by using the parent-child access level for records. For example, a regional director in the EU Business Unit may only see and manage the data and activities of the sales teams in the EU, while a global vice president can view and edit data across all Business Units. This ensures that sensitive information is protected and that users only see the data that is relevant to them.
Figure-1: typical Business Unit structure
Although Customer Insights – Journeys supports the concept of business units, however, it works a bit different than in other Power Platform applications like D365 Sales or Customer Service.
How CI-J operates
When CI-J is installed, a bunch of entities and plugins are provisioned in the environment. In addition, several security roles and application users are also created. The corresponding security roles and service users are documented in this article. Especially the application user called “Dynamics Marketing Customer Experience Platform PROD” is worth looking at. This user has several CI-J related security roles assigned that are required to operate and that have organizational access level for the required entities like journeys, emails, forms, segments, triggers (JEFST records), contacts, leads, etc.
To understand how CI-J works and why it is important to understand the underlying security roles and users, let’s especially look at how segments are used here. You can define the audience that you want to target by using a segment. The selection criteria can be based attribute or behavioral conditions and can become very complex. A segment can also be dynamic meaning that depending on the query, contacts may become members of a segment or not.
The definition of the audience is done by the query in the segment, not the visibility and accessibility of contacts of the user creating the segment or executing the journey.
When the segment is marked as “ready to use”, the calculation of the members starts in the background executed by the service user mentioned above. The contacts that belong to the segment are stored in specific data formats to make it most efficient for a journey to access and retrieve the audience data. In that process, it does not matter which privileges the user that created the segment has.
Business unit scoping in CI-J
We learned how CI-J operates inside when it computes a segment in the last section. For instance, a user with the level of “Dealer 1” in the above figure 1 can target more contacts than their access level allows when they make a segment. The query for the segment decides which contacts belong to the segment, but the user's security role at that time does not limit which specific contacts are included, because the segment calculation (which contact is part of the segment) is performed by the service user mentioned in the previous section. This also applies to the journey execution. These processes cannot consider the security boundaries of the user who created the artifact, because they are backend services running with specific privileges. CI-J has a feature that allows you to filter the audience of a segment or a journey by using Business Unit scoping. There is a switch that lets you activate this feature. An administrator can enable Business Unit scoping in Customer Insights - Journeys at an environment level. When this feature is on, all marketing artefacts and especially the JEFST records (journey, email, form, segment, trigger) that are created in the environment will be automatically scoped to their business unit. The value of the business unit is determined by the user who creates the record. This also works with the concept of modernized business units if the business unit needs to be changed for such a record after creation (see also section “BU-Scoping and modernized business units below).
The following picture shows a high-level relationship diagram for the different CI-J tables. As you can see here, the main artefacts are related to the Business Unit table:
Figure-2: relationships in CI-J tables
Enabling this feature will result in the following behavior of the system:
- segments only include audience members from the same business unit as the segment, even if the selection criteria does not include business unit filtering.
- journeys only process audience members that belong to the same business unit as the journey.
- journeys automatically filter the segments, emails, text messages, push notifications and trigger-based journeys that can be used in a journey to those that are in the same business unit as the journey. If there is a segment in another BU (because it has been created by another user or assigned by someone else), it will not show up in the list of segments to start a journey with.
- each message or template is automatically scoped to the owning business unit. A message or template can only include elements from the same business unit as that of its owning business unit.
- each form is automatically scoped to owning business unit and when submitted, creates records in that business unit.
Let’s look at the business unit structure below and assume the following:
- there is a security role setup that enables a parent-child visibility of contacts so that the regional director sees all contacts in “Market 1” as well as in business unit “Dealer 1”, “Dealer 2” and so on
- “Market 1” has some contacts associated and also some marketing artefacts
- The same is for business unit “Dealer 1” where there is also a user called “Sales Rep”.
Figure-3: Business Unit scoping differences
If business unit scoping is turned off and nothing else is configured, all marketing artefacts can be used on every level, for example, “Journey 2” could use “Email 1” to send out messages. “Sales Rep 1” would even be able to include the contacts associated to “Market 1” by using a segment query like “select all contacts which are female”, although this user would not be able to access the records associated to “Market 1”, in this case “Tracie Buscher”.
If business unit scoping is turned on, the execution scope of the marketing artefacts is narrowed down to the business unit of the artefact itself. This means:
- “Journey 1” could only use “Segment 1” and “Email 1”
- “Segment 1” defined with the query “select all contacts which are female” would only include “Tracie Buscher”
- The same is for “Journey 2” and so on.
Even though the “Regional director” has also access to contacts in “Dealer 1”, “Segment 1” will not include those records.
We will reflect on the different aspects for these two options in the subsequent sections. For customers and partners, it is very important to understand this concept as well as the challenges and with that making the right decisions for implementing CI-J.
BU-Scoping and modernized Business Units
Modernized Business Units in Dynamics 365 is a new feature that allows for more flexible and granular data access management. It enables administrators to define custom security roles and access levels for users within a business unit, allowing for more precise control over data access and user permissions. This feature is particularly useful for large organizations with complex data access requirements such as matrix data access structures.
Using this concept for CI-J means that a marketing user would be able to set the business unit for each of the JEFST records and therefore make it available for a specific business unit.
In cases where a BU-scoped execution is required and there is no user in that BU to create the records, this could be a solution.
Challenges with business unit scopin g
Under these conditions, there is a significant difference to the way this construct works in the other modules. Let’s look at some of the challenges that come along if Business unit scoping is turned on.
Centralized control vs. local configuration
As mentioned above, Business Units are a common concept to restrict availability of functionality and visibility of data to different groups of users. However, for Marketing departments, the situation might be a bit more complex.
One of the challenges that Marketing departments face is how to balance the need for centralized control and local customization. On one hand, they may want to create and maintain consistent branding and messaging across all markets, using templates and guidelines that ensure quality and compliance. On the other hand, they may also want to empower local teams to adapt and tailor their campaigns to the specific needs and preferences of their customers, using their own data and insights.
If a restrictive setup is in place with a parent-child visibility concept (especially account and contact data), this concept is not applied to CI-J and with that, it also deviates from the usual expectation that business units can share data and assets with each other.Cross-market campaigns not possible
Sometimes, marketing campaigns span over multiple local markets. If those markets are separated in different business units, it would not be possible to create cross-market campaigns by a centralized marketing department. Because there is no parent-child construct available, journeys are only able to use emails within the same business unit and only contacts from the same business unit will be targeted. This prevents users from leveraging the existing resources and contacts across different business units and from creating consistent and personalized experiences for their customers.
To nevertheless run campaigns across different markets, the marketing artifacts would need to be created in each of the markets / business units which can result in additional effort.
Data privacy concerns
We saw in the previous sections that when Marketeers create segments, they might also include contacts which they don’t have access to from their security role perspective. Although accessing those contacts is not possible, this still might raise security concerns which need to be addressed appropriately.No parent-child concept
Using the parent-child security scope for user roles is a mechanism to control data access in a business unit hierarchy. But this concept is not applied to the data that journeys and segments operate on when BU scoping is turned on. Instead, the scope is always to the business unit of the artefact itself, so the journey, email, segment or form. The reason behind is because the execution of segment calculation and journeys is done by specific application users that are deployed during the installation as described above. It is not possible to process the data in the realm of a regular D365 user and applying security concepts during journey execution or segment calculation.
Real-world scenario
An organization can decide whether to turn on BU-scoping or not and depending on that decision, you would need to take different aspects into consideration like described above.
If the business unit scoping is too restrictive, organizations should think about a different approach to ensuring that the right contacts are addressed with marketing messages.
Let’s look at a very typical example on how organizations might approach this. The scenario is the following:
- an organization uses the Sales module and has established a business unit structure like in figure 1 above.
- In this BU structure, there is a separation of data for the lower BUs (“Dealer 1”, “Dealer 2”, and so on) so that users can only see the data of the BU they belong to.
- The security roles are set up in a way that upper BUs (“Region EU”, “Market 1”, “Market 2”, etc.) have parent-child visibility. That allows users located in such an upper BU to see data from all sub BUs.
CI-J is now introduced with the following requirements and expectations:
- Data restriction for lower BUs: CI-J should be used to facilitate marketing campaigns for the lower BUs and should only allow the selection of contacts within the same BU.
- Data sharing for upper BUs: We also want to run campaigns for the upper BUs and we want to target contacts in the same BU and all child BUs (parent-child concept).
- Sharing of Marketing artefacts: Marketing artefacts (JEFS records) should be shared with the whole organization
Situation with BU-scoping turned on
Out of the box, BU scoping is not turned on which leads to the discussion why users on the lowest BU level are able to create segments that could also contain users from other BUs (depending on the segment definition). The organization expects the same behavior in terms of visibility than in the Sales module. But this is not the case and it is explained in earlier sections. So one option to look at is to turn BU-scoping on. This would have the following effect:
- Data restriction for lower BUs: A user on a lower BU (“Dealer 1”) would only be able to address contacts in the same BU which is exactly what the organization expects in this case. Even if a user would create a segment that potentially contains other contacts (“use all male contacts that live in XY”), the audience created would only create contacts that are in the same BU than the segment.
- Data sharing for upper BUs: Running a campaign with contacts in an upper BU (“Market 1”) and all child BUs (“Dealer 1”, etc.) is not possible because the segment and the journey are only able to access data and artefacts from the same BU.
- Sharing of Marketing artefacts: this is only happening within a BU. Sharing an email with another BU is not possible. All BUs must create their own marketing artefacts.
On the one hand, we can fully satisfy the requirement for data restrictions on the lower BUs. However, cross-BU campaigns are not possible, and all marketing artefacts need to be created in each of the BUs. Especially in this situation, the concept of modernized BUs can help. This would enable Marketing people which are not part of a lower BU to create Marketing artefacts for a lower BU by simply assigning the artefact to the corresponding BU.Situation with BU-scoping turned off
With all the limitations of Business Unit scoping, customers often choose to keep it disabled.. In that case, the situation would be the following:
- Data restriction for lower BUs: Assuming that a user on a lower BU (“Dealer 1”) is restricted to access only contacts in the same BU due to the security roles, this still applies when BU scoping is turned off. However, it would be possible for such a user to create a segment with a query that would potentially also include contacts from another BU. These contacts would be members in such a segment, nevertheless, the user would not be able to open the contact form because the security boundaries are still in place.
- Data sharing for upper BUs: since the visibility of contacts is not restricted by BU-scoping, a user in an upper BU would easily be able to create cross-BU campaigns.
- Sharing of Marketing artefacts: this requirement is also fully addressed. Lower BUs can benefit from other Marketing artefacts that have been created centrally.
The critical point here is that a user in a lower BU would be able to address (not access or see or edit) contacts from other BUs. There are ways to mitigate this:
- Educational: users must be trained to create Marketing artefacts, especially segments. There could be an organizational directive to always include a query parameter that ensures to include contacts from the same BU.
- Technical: when a segment is created, there could be a check routine that tries to figure out if the segment definition contains a part which filters the audience by the current BU and depending on the result, a warning could be displayed to the user. Another option would be to directly modify the query parameter to ensure the selection of the contacts in the right BU. This can be achieved for example by adding an “intersect” statement to the segment query. Adding code dynamically must of course be tested thoroughly to avoid invalid statements.
- Organizational: if a journey should go live, there could also be an approval process that requires a second person to check the correctness of the journey and also the segment.
Summary
The concept of BU and BU scoping work differently in CI-J. Instead of trying to reflect a complex security concept from sales or service to CI-J, check the options and the possibilities in CI-J and reflect those with the requirements of the customer. Keep in mind that although there might be situations where users can include more contacts in marketing activities than they should, they would not be able to access them. It’s important to weigh up whether the BU scoping’s restrictions justify the effort required to create additional artefacts or if the security risk is classified as low, so no BU scoping is necessary if additional mechanisms are in place.
