Best Practices: Assigning Security Roles & privileges

(2) Share

Report

Posted on by SErf

659

Hi,

we are right now redefining our Security Roles structure and I wondered what is the best practice to assign roles to users.

Our organization works with the following job descriptions:

Sales:

- Sales Manager

- Sales Clerk

Customer Service:

- Support Manager

- Support Clerk

Finance:

- Quote Backoffice

- Order Management

- Invoice Management

My idea now was to create a Team for each job description.

So e.g. there is one team: "Sales Clerks" and I assign the team all necessary security roles. And assign the members to that team.

- Do I need to use the Team-based "Security Roles" or "Direct User" access levels for this to work?

- Is this a good idea? What are your solutions?

- It is certainly easier to just assign a new employee to a Team than setting up security roles individually

- Should we use Azure AD Groups in any way?

- Any resources regarding this topic that I should read?

Thanks.

I have the same question (0)

All responses (2)

Answers (0)

Ana Pereira on at

Like (1)

Report
Copy link

Link copied!

Hi,

I think this documentation will assist you on your questions

https://docs.microsoft.com/en-us/power-platform/admin/security-roles-privileges#team-members-privilege-inheritance

Teresa

Was this reply helpful? Yes No
SA-30061402-0 37 on at

Like (1)

Report
Copy link

Link copied!
You may find this excellent series of blog posts useful, from Guowei Xu

Dynamics 365 CRM Development Standards and Best Practices

Particularly the section on security roles

Key takeaways from his post are:

To control data access, you must set up an organizational structure that both protects sensitive data and enables collaboration.

To ensure that users can view and access all areas of the web application, such as entity forms, the nav bar, or the command bar, all security roles in the organization must include the Read privilege on the Web Resource

Not Recommended

Creating a new security role from scratch will cause a lot of problems.

Don’t Rename an existing security role.

Don’t change the default roles. There is no reason to do that.

Some of the ways we can achieve best practice in assigning and utilising RBAC are:

Inheriting/extending from existing security roles, to avoid creating them from scratch.

You can design a hierarchy of roles, with increasing access. A managing director should not be restricted from doing things an entry level employee can do

Renaming or changing default roles can cause cascading issues with permissions and is universally a bad idea

start by mapping out user personas and roles within the business or organisation and then fill out a hierarchy diagram

you can begin to map users/roles/permissions resources like this:

https://media-exp1.licdn.com/dms/image/D4E12AQGzCU2goiI_nQ/article-cover_image-shrink_720_1280/0/1664827958184?e=2147483647&v=beta&t=1gRVKGi7SKPSI8W9YO-E3QpfUdUfAmCRErgE1No1jQ4

1 people found this reply helpful.

Was this reply helpful? Yes No