2021 Release Wave 2 Updates to Business Units, Security Roles and Users in Dynamics 365 CRM and Dataverse

Introduction:

Power Platform security framework has received an update in the latest 2021 Release Wave 2 that is currently shipping across geos.

Security framework has not seen much change in recent times with last change being introducing hierarchy security if I remember well.

The security framework in Dynamics 365 CRM or Power Platform comprises of

1. Business Units
2. Security Roles
3. Users

Exploring these with the new updates

Traditionally Users were tightly coupled with Business Units, i.e you need to choose the business unit to which a user belongs. User can only belong to a single Business Unit. And records owned by users were automatically part of the BU to which the user belonged.

There could be multiple business units within the root business unit and that supported the idea of a hierarchical department structure within an organization. However, Business Units provided a HARD divide

Given the above organization and BU hierarchy defined in CRM, users of BU1 would not have visibility or access to records owned by users of BU2 and vice versa, unless they were provided with Organization level access privileges to.

If we had Account 1 owned by U1, the business unit for Account was automatically set to the business unit of the owning user i.e BU1.

With the latest release it is now possible to decouple the business unit from the owner of the record.

Given that currently this is what U1 can see with a business unit privilege to read accounts

When you move the user from one business unit to another, you now have the following options available

Earlier, when you changed the BU of a user, the security roles assigned to the user from the previous business unit were removed.

Now, you have the option to set the behavior for security roles as well as decide if the records follow the user to the new Business Unit

Source: Create or edit business units – Power Platform | Microsoft Docs

Currently these settings are not available on the Settings UI to modify but these can be edited using the OrgDBOrgSettings community tool available. You can download the same from here.

Look for the following settings and set them to True

• EnableOwnershipAcrossBusinessUnits
• DoNotRemoveRolesOnChangeBusinessUnit
• AlwaysMoveRecordToOwnerBusinessUnit

With this done you basically break the “HARD” division of BU that we spoke of earlier.

With this enabled now when you try to move U1 to BU2, the following screen shows up, notice that the move records to new business unit is unchecked.

We set it to BU2 and move the U1 user to BU2. By setting all the above 3 settings to true, you will notice the following which is different from how it used to be earlier.

Check security roles of U1, currently the UI does not support displaying security roles across business unit so instead check the security role of BU1 and you will see that User 1 continues to be assigned the security role that was created in BU1

Since this role is still assigned to the user, and per this role – a user has BU level read access to Account records in BU1.

When User1 now looks at the Active Accounts list, they still see the following, which is the list of records from BU1 even though they have been moved to BU2, this is because they still have the security role from BU1 assigned to them which allows them read access to BU level

Now since the user has been moved to BU2, we need to assign a role to this user from BU2. This brings the next update for us to discuss.

Earlier, security roles were created at the root level and these security roles were inherited by the child business units. You are now allowed to create a security role at individual BU level.

Let us go ahead and create a custom security role for BU2 that provides BU level read access. We can do that by copying an existing security role from the same BU.

Here is the role we created

Now we assign this role to U1 that we moved to BU2

After this change when we refresh the Active Accounts view for U1, this is what we see

They can now read records from both BU1 and BU2 even though they belong to BU2 now. This is because we can now assign security roles from different business unit to a user.

Possible Issues and complications:

One of the issues that one can come across by setting the AlwaysMoveRecordToOwnerBusinessUnit option to False is the following.

Working with sample data, the records were owned by a user belonging to root business unit. Now when you change the owner of these existing records to another user that belongs to another business unit, you will see the following error “Assignee does not hold the required read permissions….”

This is because the owner of the record will change to the assigned user say U1 but the owning business unit for that record does not change since we turned off the setting to move record to owner business unit so the BU for this record continues to be the old one. Now U1 only had BU level permissions of their specific BU. They do not have any security roles assigned from the old BU.

Now go and assign a security role to U1 from the old BU and try to assign the record to the user and it will go through successfully. The owner of the record does not belong to the same business unit as the record and yet is allowed to own that record.

Conclusion:

These updates could be useful in scenarios where users may be required to be provided access to records that do not belong to their business unit but certainly need to watch out for unexpected repercussions such as the above.

Note: As of the date of publishing this article, this feature is still in public preview.