Business Units in Dynamics 365

Businesses across the world are always divided into multiple departments or divisions for the administrative purposes from older times. Each of these divisions or departments work in their own way with their processes, products, customer and so on. In some organizations, we could find overlap or collaborations between these divisions or departments which is quite obvious. When we think about setting up a system for an organization, we need to consider all these aspects as its quite possible that depending on how the organizations works through collaborations the data accessible for users from one division or department might not be accessible for users from different department or they might only have read access to the data but not able to make any changes to the data. Being said that when we plan for a security architecture for the system these thoughts should be considered. The best way of implementing this would be to first logically groupings all these related activities together and then provide users access to each of these groupings depending on what they can access and what they can change. Dynamics 365 offers an option for this via Business Units. Business Units are the logical grouping or related business activities. In this blog, we will discuss about this capability in Dynamics 365.

Along with business units, security roles and users are linked together to control the data access to people so that they see information they need to do their jobs. To elaborate on that, normally users can securely access data in their own business unit, but they can’t access data in other business units. That way already the user is restricted here from accessing only the data available for his or her department/division. On top of this, we can also set security roles which can only access, data which is given access by the administrator. This happens within the business unit which they are part of. This is the second level of security cover, we are giving to the data. More on the security model, we will cover in a separate blog. In this, lets concentrate more on the business unit.

When it comes to business unit there are couple of more information which we need to keep in mind so that we are pretty much aware of what this is all about and how we can use this concept to our advantage.

1. Root business unit also know as the organization is the top level of a business unit hierarchy.
   1. This is automatically creates when we provision the system for the very first time.
   2. We can’t delete this organization.
   3. The name of this organization is derived from the domain name when the environment is provisioned.
   4. We cannot change the name of the organization using the dynamics 365 forms.
   5. We can change the name of the organization using the Web API.
2. Each business unit can have only one parent BU while they can have multiple child business units.
3. All users must be assigned to one and only one business unit.
4. All newly provisioned users are assigned by default to the root business unit. We can change that at any time later.
5. Each business unit had a default team whose name cannot be updated or we cannot delete the default team.
6. We cannot add or remove users from the business unit’s default team.
7. Security roles can be assigned to the default team which will simplify security role management where all BU members can share the same data access.
8. We can assign additional team to a BU but there can only one BU per team.
9. A team can consist of users from one or many BU. This is the scenario where there is a need of collaboration between users from different departments/divisions.
10. When we change the business unit for a user, we remove all security role assignments for the user. In the new business unit at least one security role must be assigned to the user.

Make sure you keep the above points in mind when we plan to have a security strategy for an organization. Any user having a System Administrator or System Customizer role or equivalent permissions to create or update a business unit. They can navigate to Business Unit by logging into the respective environment and then navigating to Settings -> Users + Permissions -> Business Units. Similar we can also delete an existing business unit from the system. But its very important that before we delete a BU, consider the following points,

1. Once we delete a business unit, this is a permanent action and we cannot reverse this action. So think twice or more before we take a decision to delete a business unit.
2. Records owned by this business unit will also get deleted as soon as we delete the BU. This includes for example, Teams, Facilities/Equipment and Resource Groups.
3. We can’t delete a BU until we reassign all the BU records to another BU.
4. Before we delete a BU, we need to disable the same. When we disable a BU, all users and teams associated with the BU will not be able to sign in to the system. We need to reparent users and teams to another BU and reassign security roles. Otherwise, you will be getting an error when we try to delete the BU.

Another option we have it so reassign a business unit to a different parent business so that the hierarchy in the system is aligned with the business strategy. When we does this any child business unit are also reassigned along with it. For this in the BU record, we have an option Change Parent Business which can be used.

As you might have seen, while we are considering the security model/matrix for an organization the how important the role played by a BU is. So, instead of considering the BUs as mere records created in the system, this should be thought from a very high level which could have larger implication at large for the organization data as well as the security. Because of all these we need to take the BUs more seriously and think multiple times before we make changes to existing BUs.

Thank you for spending time reading and appreciate if you share your comments below.