A security model in Dynamics 365 protects the Data Integrity and Privacy in a D365 organization. As a D365 Customizer, Authentication and Authorization of the D365 application is called security testing. Security roles in D365 have both Privileges and Access levels for each Entity. As you are planning to validate your system, always remember these important points:

Test Plan

• Level of Access: The D365 security model provides different levels of access, like User, Business Unit, Parent, Organization, to each security role. Consider all the security roles defined in the system and perform validation from highest – like System Administrator to lowest against the requirements defined for your system.

• Privileges: The D365 security model provides different privileges, like Create, Read, Write, Delete, Append, Append To, Assign, and Share, for all the roles defined in the system. Plan to perform all the CRUD operations and validate which type of role is authorized to perform those actions for each entity.

• Field Security Profile for users: Field level security in D365 is applied to control access to individual fields within an entity. It is applied to single user or team. Authenticate whether users or teams who are added to the field security profile in the system have privileges to read, write, or update those fields in different entities. Ensure users who are not part of the field security profile team are not authorized to read, write, or update those fields and that a symbol (*Lock) is applied.

• Teams: D365 is a collection of users who belong to the same or different business units. A user can belong to multiple teams. A user belonging to a team has all the privileges that the team is entitled to, except if the user has been restricted from some of them. Perform negative testing to identify whether any unauthorized users have access to edit those records.

Test Execution

• Have the security matrix Excel sheet with access levels, privileges for all entities defined by your Business/Customer
• Create test cases around the security matrix for all the security roles
• Start your testing with lowest level of security role and then complete your testing with the rest of the roles defined in your system
• Consider which is the security role that your business or customer uses most in their day-to-day activities and execute the regression suite test cases with those security roles
• Consider negative testing on Field level security fields and Teams
• Validate out-of-the-box actions like Delete and Deactivate buttons are disabled for User security roles who are not supposed to have access
• Verify Reports and Dashboards are only available to User Security roles who have permission to access
• The customer values security as the highest satisfactory point, so ensure users can perform all operations they are supposed to perform, and that an unauthorized user can’t perform the actions that they are not supposed to perform

That’s it. You’re ready to test security roles within Dynamics 365. For more tips and tricks, be sure to subscribe to our blog!

Happy testing!