Security module overview
In the Security model overview section of the template, you should provide a high-level overview of the attendees' security model. The details don't need to be extremely granular because each specific area will be discussed in detail later in the template.
Next, answer the question of how you are managing access to records. This information is helpful to know if specific restrictions are in place on data (such as salespeople only being allowed to view their own customer data) or if other special data access information will impact the security model. In addition, this section can include technical details, such as the requirement to have multifactor authentication to access system data.
Basics
Two slides in the template cover basic information about the security model. The following questions are included on these slides.
How many users do you have (target)? - The number of users has a significant impact on the scalability of your security model. For example, if the customer is relying on sharing records to provide access, they should be aware of the potential performance impact when many records are shared between many users. Some security models that are acceptable for small user counts become unsuitable as user count grows. For that reason, it's important to consider current and expected future user growth.
How many distinct security patterns or configurations do you have in your model, and how many users are in each pattern configuration? - Security pattern refers to the different security configurations that the customer wants to implement to answer the requirements. For example, people in the sales department will use the standard use of user security roles, people in customer service will use a combination of user roles and manager hierarchy, and people in marketing will only use access teams. By determining the expected number of patterns, you'll identify if the security model will be overly complicated or difficult to maintain long term.
What percent of users potentially have more complex security requirements than the rest? - Customers sometimes over-complicate their security models by designing around niche exceptions to the standard process. When you identify the existence of many different non-standard requirements, you should question the requirement and recommend standardizing on the main process.
Do you need to restrict access to data or filter access to data? - This question distinguishes between convenience filters and real security requirements. Wanting to provide users with a simplified view of data that matters most to them is a good goal; however, security shouldn't be used to achieve this objective. Use views to filter data while leaving access to other records available.
What number of security roles do you need? - Keeping the number of security roles to a minimum makes administrative tasks easier to manage. Dynamics 365 includes many standard security roles for standard user types like sales manager, customer service rep, and system administrator. These roles should be used as the basis for the customer's security roles.
If requirements differ from standard roles, consider creating copies of standard roles and iterate from them.
Have you created new security roles instead of customizing existing ones? - A recommended best practice is to save a copy of one of the standard security roles rather than creating a new one.
Security roles include many permissions that are required to get into the application, and creating a new role is problematic because the customer likely won't have all necessary base permissions.
Remind the customer that new permissions are frequently added to the standard security roles by using regular application updates, and these new permissions aren't automatically added to existing custom security roles. If custom security roles are used, someone will need to remember to identify the newly added permissions and update the custom security roles following each update to ensure continuity of system access after updates.
Have you tried to reduce the number of security roles as much as possible? - The more security roles that a Dynamics 365 deployment uses, the more difficult it will be to administer long term. When new functionality is added, if 25 separate security roles are available, and the functionality is needed by everyone, then the maker will need to update 25 security roles to provide access to the new feature.
One popular strategy is to use a base role, which provides the baseline of functionality that is needed to sign in to the application and all tables that are available to all users. Next, supplement that role with extra roles with the role-specific features that are needed by that role.
For example, if all users need to read accounts, but only the sales managers should be able to create new ones, your base role would contain organization level account read permission, and the sales manager role would only include account create permission. Then, if a new feature was added that all users need, it can be added to the base role only.
What's the number of security roles that an individual person needs? - The more security roles that need to be added to an individual user, the more complicated user onboarding will become, and the more likely that someone will make mistakes. If many required roles exist, these roles should be consolidated to help make ongoing administration easier.
Another approach that can help is by using Microsoft Entra ID security group or Microsoft Entra ID Office group teams so that you can grant the roles once to the team and then the users will automatically inherit the roles for the team (so, in the context of the team's business unit), after being added to the appropriate Microsoft Entra ID group.
Are the security roles created at the root business unit level or at the child level? - While you can create roles that are specific to one child business unit, we recommend that you create security roles and edit them at the root business unit level.
Creating roles at the root business unit level makes the role available to all business units, while child-level business unit roles are only available at a single business unit level. If you have a business unit-specific role, when you move a user to another business unit, that role won't be available. Otherwise, you'll have different versions of the same role at a different business unit, making the system difficult to administer.
What's your strategy to update the security roles as you roll out new tables and functionality? - In a rapidly changing environment with continuous development, it can be easy to forget to update roles, or only test with system administrator access, and miss updating security roles to include the new functionality. The customer's strategy should include a process for updating security roles and testing with each persona's role mix whenever a new configuration release is rolled out.
Reasons for this information
The reasons why you should ask for the preceding information from your attendees is because:
It's rare that one security pattern suits all user needs and roles. You need to understand how many different patterns you will need to implement in the project.
Complex security models are frequently designed to accommodate the needs of a fraction of users that don't fall into the main model. In that case, an opportunity to challenge could exist if those users couldn't access the desired data in a different manner or elsewhere, such as reporting.