Scalability, performance, and maintainability
In this section of the template, you examine questions that identify if potential issues occur when the application scales to additional users and the amount of data increases.
Answer the following maintenance questions in the template.
Have you identified scenarios where the record doesn't need to be owned by a user or team? - When creating new tables that represent cross-company referential data and will never need granularity for each business unit, team, or user, you should consider creating them as organization-owned tables.
Record ownership is important where variable visibility or editing permission will need to be granted to different users. However, if general records exist that should be visible to all users, and all users share the same level of edit permissions (such as records that are generated by using an integration), a strategy such as assigning records to the business unit team should be considered so that these records don't need to be reassigned when someone leaves the company.
Have you identified potential scalability challenges in your security design at higher volumes? - Strategies like record sharing can work adequately in smaller deployments but can quickly become inefficient when scaled to large numbers of users.
Also, having users be members of thousands of teams in thousands of business units can be a challenge in terms of performance and scalability.
Have you considered the impact of your data and security models on the POA table? - Excessive sharing leads to a large POA table and can degrade system performance.
Do you regularly update user, team, or business unit records? - As a general rule, regular updates to user, team, or business unit tables should be avoided. For example, updating an attribute on a user table can cause the security cache to flush and potentially impact performance.
Have you considered the impact of a large reorganization to the users, teams, business units, and records? - Business structures change. New companies are acquired, divisions are divested, and people leave or move to other departments. Your structure should be flexible enough so that you can easily add or remove users, teams, or business units without requiring a complete security model redesign.
For users who already have access to a large percentage of records, have you considered providing global access for better performance? - Providing organization/global read access to records can optimize performance for the implementation of a view because the system doesn't have to consider the security principles that apply to a user (individual roles, team roles, shared records, hierarchy) when retrieving records.
While a user might have access to all records from a security standpoint, you should customize system views that will filter the number of records to only present what is relevant to their work.
Do you bulk reassign records when a user leaves? Have you considered the impact of a cascading relationship? - Relationship cascading settings for activities and other common records can cause unexpected results when you are reassigning records, and this behavior should be modified if you don't want to have closed activities reassigned when you reassign customer account and contact records.
Security testing
The security model is composed of multiple parts working together, and it has multiple areas where it could fail. In this section of the template, you will review the approach that will be used for testing security, identify the ongoing plan to monitor access to Dynamics 365, and ensure that the design of security roles is well documented and will be simple to maintain long term.
Security questions and why they matter
In the security testing section of the Security model template, answer the following questions.
Do you have test environments to validate the data in the context of your security requirements? - To adequately test security roles, your customer will require a non-production environment with the same configuration as production and a close approximation of the production dataset. While you don't require 100 percent of the data from production, the data must be similar enough to accurately test the behavior of security roles. It's also important to have distinct test users and not reassign roles to the same test users. The reason is because users who originally have higher permission might retain access to certain records when that role is removed by using record ownership or sharing.
Do you have the security matrix Excel sheet with access levels and privileges defined by your business or customer? It's important to have some documentation of security design outside of the Dynamics 365 security role in case someone changes the security role in Dynamics 365 and you want to remember how it was designed. This document can be an Excel spreadsheet that indicates the appropriate permission level by table.
Do you have test cases around the security matrix for all security roles? - The customer's security requirements likely came from the requirements that were gathered during the previous workshops in the project, and these requirements create the basis of security test cases. Each security restriction should have a test case and be tested thoroughly before go live. Then, the restrictions should be tested in the context of each impacted security role or persona.
Have you considered negative testing on field-level security fields and teams? - It's important to test if someone with a role can see secured fields and can access records that are assigned to their team. Additionally, you should verify that users without these roles or team assignments can't access these items.
Will you perform penetration tests on the platform? - For highly secure environments, penetration testing is an option. Keep in mind that penetration testing must follow the Microsoft Cloud rules of engagement for penetration testing. For more information, see Penetration testing rules of engagement.
Other Dynamics 365 security questions
In this section of the Security model template, you examine security regarding the related functions within Dynamics 365.
Provide answers to the following questions.
Have you considered the Export to Excel privilege? - Export to Excel is a great convenience and reporting feature, but it can also be a risk because some customers have had employees take client data with them when they leave the company.
It's important to be aware and cautious that, though the Export to Excel privilege might prevent some users from easily downloading data off Dynamics 365 with the Export to Excel button, whoever has a read access to a record can access that data through APIs and ultimately export it.
If applicable, how do you plan to control security in Data Export Service, Azure SQL, or Export to Data Lake and Power BI? - When data leaves Microsoft Dataverse for reporting or integration, it's no longer protected by Dynamics 365 security. Organizations must be aware of this parameter and plan for security when the data leaves the system.
If applicable, what is your security model strategy for Power Pages and Unified Service Desk? - Power Pages help you expose data externally and also allow external parties to update Dynamics 365 data. However, it's important to consider the security implications of this feature and ensure that secure and sensitive data isn't exposed to the wrong people.
If your users inherit their security roles exclusively from teams, have you considered using the Inheritance to direct user setting on security roles? When you are assigning a security role to an owner team (including Microsoft Entra ID security group teams or Azure AD Office group teams), its member's Privilege inheritance setting should be checked to ensure that it's set properly. This setting can allow users who are members of the team inherit user-level (and not business unit-level or higher) privileges as if the security role had been directly assigned to them.
This feature is useful in allowing users to own records in their name, even though they don't have a security role directly assigned to them. For example, with this setting, users can own personal views. With owner teams, security roles don't need to be granted directly to individual users, which helps reduce administration effort.
If you plan to use virtual tables, have you considered creating a security model around them? - Virtual tables enable creation of tables that don't store data in Dataverse but rather point to an external data source. While this feature is convenient, and in many cases preferable to overloading Dynamics 365 with data, you should understand that the virtual table connection uses a single data source, meaning that all users who have access to the virtual table will see the same records. If you have sensitive records that shouldn't be visible to all users, data integration is recommended.
Security monitoring
In this section of the template, you will review the customer's strategy for monitoring appropriate access rights and will identify misuse of the application. If activity audits are enabled in Dynamics 365, many user activities are logged in the Microsoft 365 admin center. By using these logs, you can identify unusual or potentially malicious activity in the system, including common actions such as:
Who published customizations
Who was added to a team
Who added a solution
Who published customizations
Who exported to Excel
Who viewed a report
Who exported a report
Standard audit logs monitor when users access the system. Tools like Microsoft Power Automate can alert you when certain activities happen, and Microsoft Entra ID can alert you when people outside of the usual geographies attempt to access the system.
In this section of the Security model workshop template, you will summarize the strategy for monitoring and alerting abnormal behavior and plans to regularly verify user permissions in Dynamics 365.
Regulations and compliance
In this section of the template, you will identify if governmental or compliance regulations are in place that might impact the security model for Dynamics 365. These regulations include consumer data protection regulations like HIPAA, and SEC and auditor concerns like business segmentation. Complete the information in the regulations and compliance slide.