Deploying Business Units and Security Model within Solution from Sandbox to Prod

Question

I am working on a Dynamics 365 project (v9.1) that has several organization environments using Sandboxes such as DEV, then a few others such as QA, etc, and finally PROD for example.

I have been told that any Security Role changes to Business Units have to be manually performed on each environment.

The reason I have been told for this is that when an environment is created the default parent business unit name is generated uniquely by default by Dynamics 365 and this results in each of the environments having different parent business unit GUIDs and this adversely affects children business units, teams, etc, so the security model each environment has to be done manually per environment.

I am very new to Dynamics 365, but it doesn't quite seem intuitively correct that Dynamics 365 would require me to make security changes manually on each environment (rather than encapsulating them within a solution from DEV).

My questions are:

1. Why are sandbox default parent business unit GUIDs not the same as PROD?
2. What is the correct approach so that I only have to make business unit, team, and security role changes on DEV sandbox and then export/deploy as solutions up the chain to PROD?

Answer 1

This is true because Business Unit is an entity record and the default parent BU is created when Org is provisioned with the same name as Org name.

• Maintain the business unit hierarchy in the target system as the same as the source system
• Retain the same business unit ID (GUID) values in the target system as the source (except the root business unit)

The root business unit is an exception of the above objectives, since it is automatically created at the time when CRM organization was provisioned. Once the root business unit is created, there is no way to change the ID (GUID) value of it primary key (businessunitid field). In other words, the root business units would always have different ID for two different CRM organizations.

Should be fixed either by initial deployment strategy like BU Migration using Kingswaysoft technique.

In case of on-premise, do a production database copy and create lower region instances using Deployment manager.

If it's CRM online, we can do a PROD refresh, Full refresh (Schema + Data) preferably once. Later on Schema only refresh whenever needed.

This way we can make sure the lower region changes (Solution with Roles, customizations, etc) can be moved to QA/PROD without the fear of non-sync environments.

BU, Teams cannot be ported as part of solution because they are table records, either using Data migration utility or Export/Import with same GUID using CSV format will work.