Role-based security simplifies the balancing act between user access and protecting your data in Dynamics 365 and Power Apps.
By implementing roles mapped to teams and duties, administrators can simplify user configurations to avoid the complexity of managing these individually.
This approach will also avoid time-consuming steps if roles and policies change. For instance, suppose a service team should now have permission to create lead records. Using role-based security, this change could be made once and immediately applied to all users.
As individual responsibilities change, access can easily evolve through centralised role changes rather than making individual tweaks.
Thoughtfully structured roles save admin time, create flexibility to scale, reduce access-related confusion for users, and help protect data to ensure compliance.
Tightly controlled access through centralised roles helps administrators adhere to security policies while effectively supporting end users across an evolving organisation.
Let’s dig deeper into constructing roles for access control and usage needs.
How to Manage Dynamics 365 Security Roles
To configure and assign security roles, navigate to the Power Platform Admin Center.
After selecting your environment, admins can choose “Security roles” under the “Users + permissions” section. This will list all existing roles where adjustments can occur.
Changes will immediately be published in Dataverse upon saving. Dataverse refers to the common data model and storage capacity underpinning Dynamics 365 and Power Apps.
No matter where data is created or edited within Dynamics 365 or across the Power Platform, updates are routed through to Dataverse records and structures behind the scenes. This allows the Power Platform Admin Center to push role permission changes out to apps in real-time.
Security Privileges and Properties
Think of a security role like an ID badge that gets you into certain parts of a building. For Dynamics 365, these give people access to the data and tools they need to do their jobs.
For example, the types of access include:
- Privileges for accessing specific entities.
- Supported actions using access levels assigned to each privilege. These include creating, reading, updating and deleting data.
- Examples of additional options can include granting user permissions to export data, print or make customisations.
For Dynamics, the security role privilege editor uses coloured icons to explain the level of access. This includes:
- Global access to all records in the organisation for a specific table.
- Local access to records in a specific business unit.
- Basic access enables users to access records they own and records that are shared with them or the team they belong to.
Above: An example Security Role table tab showing the privileges for a sales manager security role.
Each security role will be assigned multiple privileges to reflect these responsibilities. This could result in an individual user having varying permission levels across different entities and records. For instance, a sales development role may have global access to accounts but only local access to lead records.
When building security roles in Dynamics, administrators assign access permissions aligned with roles and responsibilities. This is designed to avoid over-granting people access permissions they don’t need while ensuring that individuals can complete their work and collaborate.
An individual user can be assigned multiple security roles. These privileges are cumulative so that a user would receive the privileges granted by each assigned role.
Best Practices for Configuring Security Roles
Configuring security roles requires careful planning to explore long-term access needs, organisational structures and future plans.
Here are our recommendations for mapping and managing roles:
- Check existing security roles before creating new ones to avoid potential duplication, which could heighten security risks.
- Name roles clearly based on their actual purpose, like “Marketing Campaign Editor” or “Outbound Sales Development.”
- It’s best to assign multiple narrowly controlled roles rather than a few far-reaching ones. This approach aligns with the principle of least privilege to safeguard data.
- Consider combining different access levels across tables/entities to refine visibility. For example, a Support Agent role may grant local user-level access to cases with create and update privileges. However, this role might only allow read-only access to company-wide knowledge base records.
- Continually evaluate roles against compliance regulations in your industry. Adjust and refine these as appropriate to meet evolving audit standards.
Next Steps
Security role configurations and governance require vigilance and continuous care. As new features are introduced, workgroups restructure, and responsibilities evolve, changes to these setups are often needed. We recommend reviewing roles regularly to prune unnecessary access or amend to support additions. Recently, Microsoft released a new interface to control security roles through the Power Platform Admin Center. We’ve covered how you can take advantage of this enhancement.
Our team brings expertise to support administrators by creating and refining roles that serve user requirements while upholding data security policies. For instance, we can help with role optimisation assessment, implementation assistance to configure new roles and data governance guidance. Contact us to learn more and discuss your requirements.
Learn more about security roles for Dynamics 365 by visiting learn.microsoft.com
Related:
- 5 Best Practices to Reinforce Security in Dynamics 365
- Empowering Dynamics Admins with a New Security Roles Interface
