Share
Report
5Hi,
I’m hoping the community can help me understand and resolve what is turning out to be a complicated implementation of the Matrix data security model in Dynamics 365 .
We have multiple environments, each with the same three Business Units (BU):
Org (Root BU)
BU A | BU B
'BU A' and 'BU B' are child business units to the parent root 'Org' BU.
In Azure portal I have set up two Azure Security groups. We then have the corresponding AAD Security Group Teams set up for these groups.
I’m trying to establish specific security roles for each child business unit and have these roles automatically inherited via the AAD security team when a user is assigned to it. For example:
Joe Bloggs is assigned to the AAD security group team ‘Team A’, inherits the security role 'Role A' which belongs to 'BU A'. This should provide Joe with read permissions only to records owned by 'BU A'.
Then taking advantage of the new modernised business units and record ownership across multiple business units features, Joe is then also assigned to AAD security group team ‘Team B’, inherits the security role 'Role B' which is assigned to the 'BU B'. Joe now has read permissions to records owned by both 'A' and 'B' child business units.
My understanding of this is based on the resources from Microsoft Learn (See further reading at end of this post).
I’m hoping the community can help me understand and resolve what is turning out to be a complicated implementation of the Matrix data security model in Dynamics 365 .
We have multiple environments, each with the same three Business Units (BU):
Org (Root BU)
BU A | BU B
'BU A' and 'BU B' are child business units to the parent root 'Org' BU.
In Azure portal I have set up two Azure Security groups. We then have the corresponding AAD Security Group Teams set up for these groups.
I’m trying to establish specific security roles for each child business unit and have these roles automatically inherited via the AAD security team when a user is assigned to it. For example:
Joe Bloggs is assigned to the AAD security group team ‘Team A’, inherits the security role 'Role A' which belongs to 'BU A'. This should provide Joe with read permissions only to records owned by 'BU A'.
Then taking advantage of the new modernised business units and record ownership across multiple business units features, Joe is then also assigned to AAD security group team ‘Team B’, inherits the security role 'Role B' which is assigned to the 'BU B'. Joe now has read permissions to records owned by both 'A' and 'B' child business units.
My understanding of this is based on the resources from Microsoft Learn (See further reading at end of this post).
Matrix data access structure (Modernized Business Units)
Customers can use an organization structure where data is compartmentalized in a tree-like hierarchy, and users can work and access any business unit’s data regardless of what business unit the user is assigned to.
For each business unit that a user needs to access data, a security role from that business unit is assigned to the user. When the user creates a record, the user can set the business unit to own the record.
You can use an Azure AD security group to map your business unit for streamlining your user administration and role assignment.
For each business unit, create an Azure AD security group (via Azure Portal). Then for each environment, create a group team for each Azure AD security group. I think this means an AAD Security Team via Power Platform Admin Centre. Assign the respective security role from the business unit to each group team.Users will be created in the root business unit when the user accesses the environment. It's fine to have the user and the group teams to be in the root business unit. They only have access to data in the business unit where the security role is assigned.
Add users into the respective Azure AD security group to grant them access to the business unit. The users can immediately run the app and access its resources/data.
In the matrix data access, where users can work and access data from multiple business units, add the users to the Azure AD security groups that mapped to those business units.
If my understanding of the above is correct, there appears to be numerous issues to reliably implement this across multiple environments.
Issue 1: Exporting Business Unit Security Roles to another Environment
We can only add to a solution, security roles that belong to the root org business unit (which undermines the whole point of managing matrix data access via one or more child business unit security roles).
If I attempt to add to a solution, a security role belonging to anything other than the org root business unit, I receive this error –
Subcomponent 3937b825-4b1a-ee11-8f6c-6045bdd0ef2e cannot be added to the solution because the root component Role is missing”. There appears to be no way around this.
If I do create a security role to the org root business unit so I can export it via a solution, I have no way of then later updating it with the child business unit. It appears a business unit can only be associated on the creation of the security role.
Therefore, it’s impossible to export a solution containing security roles to child business units, to another environment e.g. UAT or Production even when the child business unit GUIDs are the same across each environment. Why is this?
From the limited information I’ve found online, it appears that to implement the AAD security-managed matrix data access model across multiple child business units, we need to configure any security role which belongs to a child BU, manually in each environment. This seems very antiquated and not consistent with deployment best practice.
Issue 2: User's default business unit is always the top level root org
We want our IT team to license and add users to the appropriate AAD security groups via https://portal.azure.com so users are automatically assigned to the corresponding AAD security group teams; with the appropriate child business unit security roles inherited from these teams.
We don’t want general users belonging to the org root BU but this seems to be the default any time a user is added to an environment. This means the IT team then must remember to manually locate the user’s record in D365 and update the user’s default org BU to a child business unit. The risk otherwise is that general users by default will gain access to all data in the org where role table permissions are set to org or parent-child business unit.
For reference, here are the links to further reading:
https://learn.microsoft.com/en-us/power-platform/admin/create-edit-business-units
https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds
https://stackoverflow.com/questions/60158049/deploying-business-units-and-security-model-within-solution-from-sandbox-to-prod
https://www.microsoft.com/videoplayer/embed/RWOdR4
https://dynamics-chronicles.com/article/dataverse-modernized-security-model-business-unit
https://www.ariclevin.com/powerapps/post/security-roles-ppac/
https://www.inogic.com/blog/2022/09/record-ownership-across-business-units-preview/
https://stackoverflow.com/questions/19308133/how-do-i-export-import-business-units-security-roles-in-dynamics-crm-2011
https://stackoverflow.com/questions/26779155/cant-edit-security-roles-from-non-default-business-unit
http://www.kingswaysoft.com/blog/2013/06/25/Migrating-Business-Units-using-SSIS-Integration-Toolkit-for-Microsoft-Dynamics-CRM
Any help or advice is much appreciate here! I hope this topic may help others in the community who are facing similar problems with their security model implementation. Kind regards.
Categories:
All responses (
Answers (
