Dynamics 365 Customer Engagement Security Best Practices and Maintenance Considerations

When it comes to the topic of “security” in the Dynamics 365 Customer Engagement platform, we thought we would share a few simple best practices and maintenance considerations that have been beneficial to some of our customers over the years.  This is, in no way, an exhaustive list, but hopefully provides some ideas and strategies to think about whether you are facing a net new implementation or need to clean up your current instance.

Best Practices

Below is a short list of best practices we try to follow.

Leave the OOB Security Roles alone!

The first thing you should do before manipulating a security role is to NOT DO IT!  If you need a role for “sales people”, then find the out-of-the-box (OOB) role that most closely represents what you need (like the “Salesperson” role) and do a “save as”.  For example, if your company name is “ABC Company”, save the “Salesperson” role as something like “ABC Salesperson”.

This will allow you to easily find your specific security roles, but, more importantly, it will preserve the OOB security role as a point of reference should you need to refer back to the way Microsoft had established it.

Do NOT add access to a common role for exceptions

What do we mean by this?  Well, it can be tempting to add an unrelated privilege to a role for one or two users, but that starts to break down the control you are establishing by way of that security role.  Said another way, ONLY add privileges that are required by that specific role.

If you need to provide that additional access as an exception to a few, then consider creating a special, separate security role for that specific function.

Be Very Stingy with the System Administrator Role!

One mistake we’ve seen over the years is organizations giving too many users the “System Administrator” security role.  Sometimes it is done because the company had a small number of overall users and didn’t feel the need to restrict anyone, or they didn’t feel comfortable restricting access for the executives in the company.  Other times, they don’t take the time to establish a true administrator of the instance so they just give it out to too many on the project team.

I suggest starting with two system administrators (one primary and one backup) and then everyone else will be assigned appropriate security roles for their work stream.  The number of administrators, of course, is highly dependent on the size and structure of your organization.  It is not a pleasant conversation to have when a user inadvertently deletes hundreds of accounts or contacts!

Err on the side of being Less Restrictive

We know!  We know!  We just got done telling you to be restrictive, but that is for the “System Administrator” role.  When it comes to end users, it is a quite different approach.  Outside of any obvious confidential information requirements, we suggest keeping the system access as open as possible.  “Why?” you ask?

We will answer with a question.  What is one of the biggest challenges to customer engagement (CRM) systems?  The answer is user adoption!  While providing visibility to upper management is wonderful, these systems really begin to show their benefits when they provide bottom up value to the end user’s daily routine and increase productivity.  So, just be careful not to hinder that value to the end user by being too restrictive…especially early on.

Maintenance Considerations

Below is a short list of security maintenance ideas to consider with your D365 CE instance.

Consider using “Teams” to more easily manage large numbers of users

By assigning Security Roles to a Team instead of directly to a User, your ongoing administration of the end users can be made slightly more manageable.  BUT, you do then have to commit to managing members of Teams as part of your admin processes.

In my experience, this maintenance approach is not as common, but is definitely a strategy to consider if you have large user counts and tend to assign multiple security roles per user.

Consider a combination of Security Roles based on both Roles/Position and Function

This is a good strategy to use when dealing with the scenario where someone with a common role needs some additional/special access, but shouldn’t have the next level up security role.  This relates to what we mentioned earlier in “Best Practices”.

Having this security role combination provides the flexibility needed while still maintaining enough clarity to be able to manage it.

Consider creating all Security Roles on the Root BU

Admittedly, this suggestion may be more controversial, but let us try to convince you.  With Dynamics 365, you have the ability to create Security Roles specific to a Business Unit.  Now, if your instance only has the root/default BU, then this becomes a moot point.  But, if you do happen to have multiple BU’s in your organization/instance, then this is something to think about.

If you create a security role at the highest level Business Unit, then it affords you the ability to assign that security role to a user within any other lower-level BU.  The only scenario one can think of that might warrant creating a security role at a lower-level BU would be if you have specific individuals managing the different BU’s separately.  Even then, we would rather create all security roles at the top BU level and then use a naming convention to designate it for a specific BU.

Consider using Teams with Field Security Profiles

When using “Field-level Security”, maintaining the members of the “Field Security Profile” can be made easier if you simply map a Team to the profile.

This way, all you have to manage is the Team itself.

Managing security within Microsoft Dynamics 365 Sales, Customer Service, Marketing, Field Service, Project Service Automation, or anything Customer Engagement can become overwhelming.   We hope applying some of these best practices and maintenance tips as part of your overall security strategy bring some benefit to your administrators and end users!

If you need help with core security concepts in Dynamics 365 for Customer Engagement, you might start here: https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/admin/security-concepts. If you need additional guidance, feel free to reach out.  We’d be glad to help!