Business units and teams
In this section, you provide a description of the hierarchical structure of the customer's internal organization and the business unit structure in Dynamics 365. Some relationship should exist between the business unit structure and the organization structure, but the business unit structure shouldn't be as granular as the organization structure. Though two groups are in different divisions of the company doesn't mean that you'll need to restrict visibility of records between the two groups. Frequently, multiple departments can share the same business unit.
Use a tool like Microsoft Visio, or some other visual diagram/charting application, to create a visual representation of the structure. If you already have a document that visualizes the organizational hierarchy of the company, you can paste a screenshot of that diagram in the document.
Be aware of two potential issues: too many business units or not enough business units.
Too many business units
If the proposed security model identifies that hundreds or thousands of business units will be available, this issue should be flagged as a risk. Business units are like large granite rocks; they are designed to be permanent and infrequently moved. While users can be moved between business units, it's not a trivial matter, especially if they own many records.
When you move a user from Business Unit One to Business Unit Two, the business unit association of every record that the user owns will change. This factor can cause some surprises to other users who are members of the user's original business unit, if they have business unit level read permission. The records that are owned by the moved user will no longer be available to them, but if they own child records of those records, like activities, it could cause odd scenarios to occur. Also, if the user owns many records, moving users between business units can be time-consuming.
Another potential impact from large quantities of business units is extremely slow security role updates. Each role isn't only one record. A copy of each role is added to each business unit. Therefore, if you create thousands of business units, making a small change to a security role could take hours.
A good practice is to keep your business units to a minimum. Use only the minimal number to facilitate true business unit security requirements. For more granular user segmentation, consider the use of teams. Teams are more flexible, they can be used to control security access to records, and users can be members of multiple teams.
Not enough business units
If you're implementing for a single group, it's common to only want to use the root business unit for all users.
While the "keep it simple" approach is great, a strong possibility exists that the customer might, at some point, have some pieces of data that they want to keep secret from a subset of users.
Consider the following scenarios:
You expand Dynamics 365 usage to other parts of the company.
Your company is acquired by a large, multinational company.
The CEO decides to track emails and doesn't want everyone to read them.
The VP of sales discovers several contacts in their address book that need to be in Dynamics 365 but are better kept private from the rest of the company.
Moving people between business units is difficult, and it's a process that you'll want to do only when necessary. If the customer starts with all users in the base business unit, if a change develops that requires a subset of data to be separate, the customer will have to relocate many or all existing users because the root business unit can't be reparented.
To protect against this eventuality, it might be a good idea to initially create one child business unit and then put all users in that business unit. If your business changes to require further segmentation of data, this approach will help simplify those changes because the business unit with the bulk of users can be reparented, or selected users, like the CEO, can be moved to the base business unit. A full-scale business unit move of all users can be avoided.
Teams
The Teams section of the Security model template captures details regarding the planned use of team records for security in Dynamics 365.
In this section, you will provide answers to the following questions:
Do you use owner teams to assign roles to users? - Owner teams (including Microsoft Entra ID security group and Microsoft Entra ID Office group teams) are a great way to assign security roles to users and to reduce administration effort. When a security role is assigned to a team, it's inherited by the member users but applies in the team's business unit scope.
Do you use owner teams to own records? - Team ownership of records can be considered to manage the association of a record with a business unit separately from the otherwise standard owning user's business unit. This approach can be helpful when the functional association of a record and a business unit differs from the user's association with a business unit.
Some downsides and risks are associated with team ownership of records that you should be aware of. Generally, it requires automation to be consistent and user-friendly. Some features, such as goals and forecasting, rely on user ownership of records. Also, the ability to reassign a user's records in bulk (for example when a new salesperson replaces a retiring salesperson and inherits their customer portfolio) isn't available for owner teams.
Team ownership of records can be used to simplify complex security models and reduce the need for excessive record sharing. Owner team roles grant special security permissions in the context of records that are owned by the team. Therefore, if members of a sales team should have the right to edit opportunities for which they're associated, but read-only for opportunities that they aren't associated with, owner security teams can enable this exception without having to use complex sharing.
Do you automate record assignment and how? - When a new account is created, you need to determine how you will assign the record. Additionally, you should consider whether the sales coordinator will remember to accurately assign the record manually. For important record types, such as accounts, we recommend that you have an automated process that automatically assigns records when they are created to simplify ongoing administration of the system. One approach could be storing sales person assignment by state on the territory record in Dynamics 365. Then, when a new account is created, a Microsoft Power Automate flow runs. It compares the state of address one to the territory state field and assigns the account to the appropriate territory and salesperson. Then, it sends a notification email to the salesperson to tell them to contact their new potential customer.
Do you use access teams (system or manually managed)? - Access teams are great solutions to managing special record permissions. For example, if a sales assistant needs to have edit permissions on 25 different accounts, rather than sharing the accounts manually with them, you can add them to an access team subgrid on the record, and then they'll inherit edit permissions based on the access team template that is associated with the grid. Access teams are excellent solutions because only one sharing record for the entire access team is created in the POA table rather than individual records for each person, like record sharing does (see the previous Sharing section in this module). This approach also allows administrators to see who has access to the record.
If the same group of people needs access to multiple records, access teams can also be used to share the records with that team. However, keep in mind that an access team can't own records and they can't be assigned security roles.
Do you automate access team membership? - It's common to have a matrix of people who need access to records. For example, a manufacturing project needs an engineer, an electrician, and a safety engineer. Frequently, these assignments are maintained in another system.
In this case, the access team should be used because the mix of individual people is different on each record and security access is needed for the members of the team. You can automate access team membership by using approaches like integration, actions, or plug-ins.
How do you deploy access team templates across environments? - Access team record permissions are established by an access team template. The template determines what permissions are shared with the members of the team.
One challenge is that access team template records aren't solution aware, meaning that they can't be added to solutions. When customizations are moved between environments, the access team template will need to be moved or manually recreated in the target environment. If you're automating an access team membership, the templates must have identical GUIDs across environments, as they're referenced in your logic.
Multiple approaches are available for you to use to migrate access team templates, including the configuration data migration utility, ETL tools like Scribe or SSIS, or utilities in the XrmToolBox.
Do you use Microsoft Entra ID synchronized groups to manage access rights? -Microsoft Entra ID security group teams or Microsoft Entra ID Office group teams are great for automating the assignment of role permissions to users and should be considered for larger or more complex deployments.
With Microsoft Entra ID, you can fully control permissions from a single source.
Do you have requirements that didn't fit into the standard model? - Identify non-standard security requirements. In the findings and recommendations section, recommend approaches to standardize non-standard requirements.