As a Dynamics 365 CRM System Administrator, you have plenty of tools at your disposal to be an absolute superstar. In today’s blog, we will be discussing items that make up your security model. Admittedly, this is one of the less sexy tips you’ll see in this series. But it’s an extremely powerful one that can deliver a top-notch system to your users.
Reminder! This is the second in a series of 10-blog posts that will discuss tools and tips available to you to become a Super System Admin!
What Makes Up Your Security Model?
Let’s review the components of you Dynamics 365 CRM Security Model:
There are a few important ingredients that together make your security model: business units, security roles, teams and field security profiles. There are others too, but these are the main ones that you should know about. We’ll dive into each below.
Business Units
Some organizations will leverage multiple business units. Some will not. Business Units are the foundation of your security model that control access to data.
Let’s say your company has a global sales team. There’s two main sales groups: North America and International. They should see different data based on where they report to. And Management should see everything. This can easily be accomplished by creating separate business units.
Your “root” business unit is used for any Users who should have global access to all data.
Additional business units can be set up with the root unit as its hierarchy. Assign users to the appropriate business unit.
Want to learn more? Check out the Microsoft documentation all about business units.
Security Roles
Your Dynamics 365 system came with many out-of-the-box security roles that you can use.
Pro tip! Don’t use the out-of-the-box security roles. Open the security role that came with your implementation – then Save As with a new name. Why? When Microsoft pushes changes to the security roles, you’re won’t be impacted. Those are NOT FUN to troubleshoot (speaking from experience)!
Define permission levels for users at the many, many levels within a security role. A security roles has the following access levels for Record-level privileges:
- Read: A user with this security role applied will be able to see the specific record type.
- Create: A user will be able to add a new record.
- Delete: A user will be able to delete a record.
- Write: A user will be able to edit a record.
- Assign: A user will be able to assign a record.
- Append: A user can attach another record (example: A note can be attached to an Opportunity if the user has Append rights on Note).
- Append to: Related records can be added (example: A note is permitted to be added to an Opportunity).
Best Practice! Remove delete permissions for most users. There is no undo on delete!
Security roles also have Task-based privileges. These are found at the bottom of a form and give a user privileges to perform specific tasks, like Export to Excel.
Finally, security roles come with a lot of colored circles. Here’s what they mean, direct from Microsoft documentation:
Want to learn more? Check out the Microsoft documentation all about security roles.
Teams
We’re not talking about Microsoft Teams here, just good ole “team ownership” teams from the legacy CRM days. Records can be user-owned or team-owned. Teams is another component within your security model that some organizations will use, while others will not. It’s entirely optional, but gives users the ability to see data across business units. While a team belongs to one business unit, it can include users from other business units. A user can be associated to more than one team.
Teams can be owner or access teams.
- Owner Team: Owns records and has security roles assigned to a team. Team members are added manually. Most implementations use this type of team.
- Access team: does not own records, no security roles assigned to a team. Records are shared with an access team, and the team is granted access to Read, Write or Append to records. Typically used when team members change often.
Want to learn more? Check out the Microsoft documentation all about teams.
Field Security Profile
Do you need to lock down visibility of specific fields to certain user groups? If so, field security profiles is the way to do it with out-of-the-box configuration!
There are two steps to implement field-level security:
- Enable field security on a field (column) within an entity (table).
- Associate an existing security profile(s).
To get started with field-level security, your first step is to create a field security profile in the Settings area:
Click New to launch a blank Field Security Profile, where you will add a Name and Description (optional). You’ll have to click Save before you can do anything else.
Next, use the Members tab on the left-hand side to add Teams and/or Users to your profile.
Use the Field Permissions section on the left-hand side to define secured fields access. After you have added fields with field security enabled, you can lock down a field at the following permission levels:
- Read: Read-only access to the field’s data.
- Create: Anyone in this profile can add data to this field when creating a record only.
- Update: Anyone in this profile can update the field’s data after it has been created.
Want to learn more? Check out the Microsoft documentation all about field security profiles.
The 10 Tools
Here are the tools we will review in the entire series: