Welcome to the first of new series of posts. The intent of this series will be to include 5 quick tips or best practices in different areas of Dynamics 365 and the Power Platform.

Hope you find them useful!

Security Roles are the building blocks of a successful Dynamics 365 implementation. Here are 5 quick things that I like to share with folks who are getting started with Dynamics 365 and Security Roles.

Only security roles created at the Root Business Unit (BU) are Solution aware.

When you create a security role you have the option to create them in the top business unit of your organization, also known as the root business unit, or in a child business unit.

However, when you add a Security role to a solution you will notice that you will only be able to select security roles that are created in the root business unit.

As per below, when I create ‘My Solution’ I would be able to choose Security Role 1 and 2, but I wouldn’t be able to add Security Role 3 from the child business unit.

The benefit from this is that you are able to quickly maintain and deliver your updated security roles to other environments.

Copy from an existing Security Role

This is a best practice for anytime that you need to create a new security role. Open an existing security role that closely matches your new role and do a Save As.

This will allow you to quickly create the role that has the majority of privileges you need already set up for you.

Click on the Entity Name when setting privileges!

When creating a new security role if you click on the entity name it will set all of the privileges for that entity at the same time. This allows you to quickly set privileges for an entire entity with one click.

I’ve always thought this to be an Easter egg of sorts.

Security Roles inherit the least restrictive

If you have a scenario where your users have more than one security role associated with them, either directly or through a team. The user will inherit the least restrictive privilege.

That is if the in one security role a user had a Business Unit level on the read privilege for contacts, but in a second security role it grants Organization Level read on Contact. The user will have the organization level visibility on contact records.

This is important to be aware of when your security model has multiple security roles associated with a user through a team or directly to the user.

Use a Naming Convention

A naming convention is important when creating security roles. I like to use this structure when building security roles.

Number_BU_Purpose i.e. 1_General_SalesAssociate

1. The Number prefix allows the security roles to sort at the top of the default view for security roles and separates them from the OOTB roles deployed from Microsoft.
2. BU: Most security roles are designed to work for a child business unit(BU). So the BU portion gives an indication of which business unit this security role is designed for.
3. Purpose: Purpose could speak to the job role, or the privilege it is opening up. i.e. Sales Associate or Sales manager.

Thanks for reading.

Photo by Ciprian Boiciuc on Unsplash