Assigning access and security permissions in Dynamics 365 CRM
Access and security in Dynamics 365 CRM is a pretty big topic and can be a complex undertaking when you get into the granular details. It is the system administrator’s responsibility to configure and assign access and security, but proper setup impacts every single user, and it’s not a bad idea to have a general idea of how you and your coworkers are given access.
When we zoom out and look at it in broad strokes, your admin gives you access to CRM in three main ways: security roles, business units, and field-level security.
Security roles
A security role within CRM is a collection of permissions for various tables and data within the system that determine if a user can access a table or records and what they can do to that data if they have access to it. They are created, edited, and assigned through the Power Platform Admin Center by your system administrators, and they provide granular control over what system users can see and do within CRM.
The Power Platform admin center.
The value of security roles is to limit access based on job role or responsibility. Generally, it is advisable to only provide an employee access to what they need to get their job done properly, and nothing more. This security methodology is called the “Least Privilege” approach, and security roles provide admin a quick way to assign, adjust, and revoke system access as bundles of related permissions as an employee’s job shifts. Having this control over access also helps you avoid costly mistakes that inevitably happen when the wrong employees have too much access to your system—mistakes like editing or deleting key data from the system by accident. And when mistakes like these happen, as they inevitably do now and then, you can quickly shift access to ensure it doesn’t happen again.
A user can be assigned any number of security roles; they are not limited to just one. So, for instance, you can have a salesperson role with all the standard access required to do your day-to-day sales responsibilities, and then you can have a sales manager role with manager-specific access and permissions. You can then assign just the first to your average salesperson, while your sales manager can be assigned both, so that they have all the access a salesperson will have, plus those manager-only additions.
If a user is assigned two roles that have conflicting access, the system will recognize the “most” privilege between the roles; so, if one role allows just read access for a table but another allows write and delete access too, a user assigned both roles would be able to read, write, and delete for that table.
There are a number of pre-built security roles that Microsoft has created for you to use as-is or adjust as you need. (You can also create security roles from scratch, but because that process is pretty complex, we’ll save that for another day.) What out-of-the-box security roles you have within your Admin Center is dependent on which CRM modules you have licensing for (you might have one or more of the Dynamics 365 CRM modules: Sales, Customer Service, Field Service, Marketing).
Though these out-of-the-box roles are editable, we suggest that you copy any role you want to edit, rename it something distinct, and then make edits to that role. Doing this will allow you to retain the original security role for any future use while still taking advantage of all the pre-settings. Learn about security in Dynamics 365 Business Central, as well→
Quick Tip: We highly recommend that each organization have just a few people assigned system administration privileges, as this role has a lot of power in the system, and you want to keep that power contained to just a few hands who need it.
When you set up the privileges for each table, you must set privilege levels for these abilities:
Create: You can make new records.
Read: You can open and view the record.
Write: You can make changes to records that already exist.
Delete: You can delete and permanently remove a record.
Append: You can associate current records with other records (example, you can attach a note to an opportunity if you have Append rights for the note).
Append to: You can associate records with a current record. Using the same example above, if you have Append to rights to an opportunity, you can add a note to the opportunity.
Assign: You can give ownership of a record to another user.
Share: You can give access to another user (while keeping your own access).
For each of those table privilege levels, you have levels of access within the app (from most to least privilege):
Organization: The user can access records in the whole organization.
Parent: Child Business Unit: The user can access records in their assigned business unit and all the business units that are subordinate (child) to that one.
Business Unit: Users can access records in their business unit.
User: Users can only access records that they own, as well as things that are shared with them.
None: The user has no access.
A visual representation of the levels of access possible within security roles.
Security role views
Let’s take a quick look at the legacy and new views of the security roles area in the Power Platform admin center, so you recognize each if you encounter them.
New view
Legacy view
Business units
We’ve encountered the term “business units” a few times in this blog, but if you’re wondering what it means, here we go:
Business units are optional groups that you can add within your organization. They would sit under the umbrella of your overall organization, but they act as a separation of data and records. By creating business units, you wall off data that you can provide user access to (by adding them to the business unit) or withhold access to (by not adding them to the business unit).
In addition to this, you can create parent business units and child business units underneath them for even more separation of data and access.
Business units may be useful if your organization has sister companies or acquires other businesses and needs to integrate them into your systems. Having several business units is less expensive than having entirely separate CRMs for these companies, allowing for a complete separation of data or any degree of data sharing that you want.
How might you delineate access to data between business units? Here is a simple example to demonstrate just one possibility. Say you have two business units that are sister companies. You want to be able to see all the contact and account records between the two companies but keep things like leads and opportunities just within that company. No problem! You make Account and Contact records available at the organization-level between both sister companies—each of which have their own business unit—while keeping Lead and Opportunity records cordoned off to each individual business unit.
You can also now turn on a new setting called Business units modernization that enables the “Owning Business Unit” field on a record—which indicates, as the name suggests, which business unit this record belongs to—to be editable (where before this field was locked and uneditable. With Business unit modernization enabled, the Owning business unit can now easily be changed (with the right permissions, as always).
Field-level security
So far, we’ve looked at how to wall off data between business units (both parent and child business units) and how security roles delineate granular access and permissions to tables within CRM. The final security level we will discuss today is field-level security, which can lock fields that you don’t want edited except by select individuals.
Field-level security is useful when you want to allow users to see data, but not be able to change it. Perhaps you don’t want your general CRM user to be able to change the Primary Contact on an Account Record. This is a valid need, since—although we want salespeople working on an account to see who that contact is—they are unlikely to change regularly and you may want only those in charge of an account, or system admin or managers, to be allowed to change that data.
To do this, first you need to enable column security for that field within the Power Platform admin center.
Head to Dataverse > Tables. You’ll choose the proper table, for this example it’s “Accounts.”
Then go to Schema > Columns and choose the column you want to adjust, which is “Primary Contact” for our hypothetical example.
Under “Advanced options,” find the “General” field, then toggle on “Enable column security.” Save it and there we go! You’ll do this for each field you want to lock.
After this is complete, you will then create two Column Security Profiles, which determine permissions to secure columns and can be configured to grant users or teams permissions to read, create, and/or update these columns.
So in our scenario, you would create one profile that allows a user to only view this field and one that allows viewing, creating, and editing. You’ll then need to assign these profiles to your users, and you can do so via individual users or via teams, which is a quicker way to assign access to groups of designated individuals. In this case, managers may be an appropriate group to assign this profile to.
You can find “Teams” under the “Users + permissions” area of the Power Platform admin center directly under “Security roles.”
Teams can be found under “Users + permissions” in the Power Platform admin center.
After you set up these profiles and assign them, access will be adjusted. When you next enter the Account Record, you’ll see what access you have by the icon next to the field. If the field has a padlock next to it, you can only see the data. If you have a key next to the field, you can see and edit.
Checking Access
In the course of your day-to-day work, admin may want to check in on user access, and you can do so in two places:
First, within the Power Platform Admin Center:
Go to Settings > Users.
Click on the User you want to check.
Select the “Manage security roles” action in the top ribbon, and you will see all the security roles that user is assigned.
By selecting “Manage security roles” you will be able to see and adjust user assignments.
Second, using the “Check Access” action:
Enter into a record, whichever you want to check, like an Account record or a Lead record.
In the top navigation ribbon, find the “Check Access” button. You may need to click the ellipses to open the drop-down navigation menu if you do not see it in the ribbon.
Here you will be able to identify a user and then check their access to this particular record.
Users themselves can use “Check Access” to see if they have access to an item in the system, as well, which can be helpful if they are trying to access something and need to request broader permissions from their managers.
The “Check Access” button is in the top navigation ribbon of a record.
Auditing
Admin also have the ability to set up auditing within CRM as a way to monitor important fields and data to see what changes happen, when they occur, and who makes those changes. We recommend you do so only on those fields and tables that are particularly important to your organization (because auditing records does take up space in your database). Auditing can be incredibly beneficial to rectify any mistakes or mishandled data—especially if something important is changed or deleted.
Auditing allows you to not only see what was changed, but you can also identify why this happened and prevent it from happening in the future. This may mean identifying individuals or job titles that have too much access and adjusting their access to follow the “least privilege” security approach.
We won’t go into detail about auditing, but it is set up in the Power Platform Admin Center in the same place you enabled column security for field-level view/edit restrictions, and it’s a pretty straightforward process that you can begin and adjust at any time!
Security roles, Business Units, and Field-Level security are the main ways to control access in D365 CRM apps. They offer you granular control over who has access to what, and they are all highly customizable to your security and access needs, as much of CRM is. We suggest creating a comprehensive plan for your security roles, implementing it, and then you can always adjust as you begin using the system. And we also suggest following the “least privilege” approach by assigning only what your users absolutely need, and then provide additional access as the need arises. This is how you can keep a tight hold over your user’s access and your general system security!
If you have questions about your system’s security, or you want help setting up security roles, please reach out to us! We’re happy to help.