When a Common Data Service Database is created it you then move into a Dynamics 365 Security model. This enables a complex and rich security model to be applied.
For background, this article will be based on the following high level diagram below.
Azure AD
Azure AD is used in this scenario to manage access and security to a complete application, this may be multiple apps (of both types), entities and Power Automate Flows.
Azure AD Security Groups allow for one place for membership to managed, this way if your solution consists of both Canvas Apps and Modal Driven Apps then you only need to understand what Security Groups you need to mange.
To manage and keep Azure AD a more tidy and maintainable place the naming convention for security groups I have used in the Power Platform will typically follow this convention.
SG-PP-AuditApp-Approvers
| SG | PP | AuditApp | Approvers |
| Security Group | Power Platform | Name of the complete application | A high description of what the access / responsibility the users will have in the application. |
Hopefully from the above example, it would be clear that this security group contains members that are Approvers for the Audit App that exists on the Power Platform.
I have in the past extended this further to incorporate what environment the complete application was deployed to.
Dynamics 365 Teams
When creating security for a Power Platform Application I will typically use Azure AD Security Groups and D365 Teams to control access. This is because if I create a Modal Driven App and a Canvas Application they can both use the same AAD Security Group – this is a bonus as it means you only have to mange the users in one place!
When creating D365 Teams I create them with the same name as the AAD Security Group. This just makes it easier to map the two together when you come back to the Application after 6 months and can’t remember what you called anything.
Once the D365 Team is created I then apply the Security Roles that are applicable for these types of users. In some instances it may be that more than one security role is applicable. The key that I try to follow here is that the people inside this D365 Team have a particular role inside the application and that this D365 Team provides the security and access to complete that role.
Security Roles
When creating security roles for custom Power Platform Applications I like to tie these back to the users and what the users will need to achieve with this security role.
For example, If I have two types of users Approvers and Creators I would create two different security roles. However, it may be that the ‘Approvers’ of this application also get the ability to ‘Create’ records. This model enables this by either adding the Security Role to the D365 Team that enables create or that the user is added to both AAD Security Groups.
Summary
This is principle that I have followed when developing CDS based solutions. It provides a clear way for management of access and also a consistent way that access can be managed between both CDS Database dependant components (Modal Apps, Entities) and non CDS dependant components (Canvas, Power Automate ect..).
Do you have any comments, better ways of doing this or improvements? Then get in touch!
JackBinnall 