Field Level Security in Microsoft Dynamics 365 CRM
Field-level security in Microsoft Dynamics 365 CRM apps allows you to create precise controls as to which users can edit which fields. It’s a very useful but often overlooked and forgotten feature.
I have trained many of Encore’s D365 CRM clients on how to set up field-level security for their users. Below are step-by-step instructions for how to do it, which is fairly straightforward.
The harder part is thinking through the human element of who in your company should and should not have what level of access to which fields. I’ll give you some pointers on that too.
Table of Contents
- Field Security Considerations
- How to Enable Field Level Security for a Field
- How to Create a Field Security Profile
- How to Add Users and Teams
- Field Security Profiles vs Security Roles
- What Is “Column-Level Security”?
- Best Practices for Field-Level Security
Note: There are now five different Dynamics 365 apps that serve various CRM needs, including Dynamics 365 Sales, Dynamics 365 Customer Service, and more. In some contexts, you may also see these products referred to as “Customer Engagement” or “CE” apps.
Field-level security works the same in all of the apps, and these settings will be shared across all the CE apps in your environment.
Dynamics 365 CRM apps allow you to add field security profiles to both system and custom fields. Setting up field security is a two-part process:
- Enable your field for field-level security.
- Set up a field security profile to define the privileges granted to your user(s) and/or team(s).
Security profiles can be configured to grant a combination of the following 3 permissions at the field level:
- Read (read-only access to field data)
- Create (users or teams can add data to this field when creating a record)
- Update (users or teams can update the field’s data after it has been created)
The business requirement for our example will be an organization that does not want certain users to be able to Create or Update the Actual Revenue Field of Opportunities.
Field Security Considerations
System Administrators have all privileges on all field-level security fields. Users and Teams can be added to multiple field security profiles. Once you have set your field security, users who do not have Read permission for the field will see the field itself but will only see “*****” instead of the data. The data values will be masked.
How to Enable Field Level Security for a Field
The steps below outline how to enable this feature in the classic Advanced Settings area within the CRM system. If your CRM environment has Microsoft’s New Settings experience enabled, the screens will appear slightly different for you, although the steps will remain the same.
1. Click on the Settings icon located on the top-right of your screen:
2. Select Advanced Settings:
3. The Advanced Settings Tab will appear. Click on the down arrow next to Settings and Solutions:
4. Select a solution. In this example, we will select Iteration 1:
5. The solution window will appear. Click on Entities -> Opportunities -> Fields:
6. We will select the Actual Revenue field. You can select any field of your choice or create a new field:
7. The field pop-up window will appear. Click on Enable under Field-level security profile. Click on Save and Close:
8. Publish all customizations:
9. Add your field to the form if it is not already present.
10. Publish all customizations.
Next, you will need to create a new field security profile to define your field’s security settings.
How to Create a Field Security Profile
Make sure you have the System Administrator security role or equivalent permissions.
1. Click on the Settings icon located on the top-right of your screen:
2. Select Advanced Settings:
3. The Advanced Settings Tab will appear. Click on the down arrow next to Settings and choose Security:
4. Select Field Security Profiles.
Note: You can also add Field Security Profiles to a solution if you need to export and import them later.
Note: Your system will already include a default System Administrator Field Security Profile which automatically grants Read, Update and Create permission to all fields enabled for field security. You cannot delete or modify this security profile.
5. Click on New to create a new Field Security Profile:
6. Enter a name and a description (optional) and click on Save:
7. Under Common, click on Field Permissions:
Note: Every Field Security Profile will list ALL fields for which field security is enabled and every new field will default to No for all privileges.
8. Select a field, and then choose Edit:
9. The Edit Field Security pop-up window will appear. Select the permissions that you want to assign to users or teams, and then choose OK. In this example, I want the group of users to be able to Read the Actual Revenue, but not change it or enter a brand-new value. Click on OK to confirm:
10. Click on Save to commit this modification to the system.
How to Add Users and Teams
1. Under Members, select Teams or Users. We will demonstrate the functionality with users:
2. On the command bar, select Add:
3. In the Look Up Records dialog box, select the user(s) or team(s) which should have the security settings applied for the field and then click on Select.
4. Repeat the preceding steps if you would like to add multiple teams or users, and then choose Add.
Field Security Profiles vs Security Roles
In Dynamics 365 CRM apps, Security roles control access to the different types of records in the system. Field security profiles add an additional layer in the Dynamics CRM security model by controlling user access to specific fields within the records users are permitted to work in.
Security roles grant table-level privileges to create, read, write, append, append to, and share records in CRM. In addition to privileges, roles specify the user’s depth of access when working with those records. For example, a role may grant access to a record type with Organization-level depth of access, which would allow users to work with all records in the table. Other levels of access restrict users to only working with records they own, or only records within their business unit.
I typically implement field-level security for organizations that have both sales and accounting users working with customer Accounts. This scenario is desirable for information sharing and collaboration; however, there are some Account fields that are best left to accounting team members to manage, such as Credit Hold, Payment Terms, Credit Limit, and Credit Rating. Once we enable field-level security for those Account fields, we can create two field security profiles: one for accounting team users, who will be allowed to Read, Create, and Update those protected field values and a second one for sales users, who will only be permitted to view those field values.
Importantly, field security profiles work with security roles, they do not work around them. Field-level security does not override the permissions granted or constrained by a security role. For instance, a user could be added to a field security profile that would potentially allow them to change a specific Account field. But, if they don’t have a security role that grants them access to edit Account records, that profile doesn’t matter for them.
In other words, security roles and security profiles grant access to different levels of data. You need both for a smoothly functioning system.
What Is “Column-Level Security”?
Column-level security is Microsoft’s official new name for field-level security in Dynamics 365 CRM apps. In fact, fields are now technically called columns. However, most customers and consultants still find it more intuitive to call them “fields” and “field-level security.”
If you administer CRM from the Power Platform Admin Center, look for these new terms in Settings > Users + permissions > Column security profiles.
Best Practices for Field-Level Security
New-User Onboarding and Job Changes
System administrator training should include how to add and remove users and teams in security level profiles, because this is a step that is often overlooked in new user onboarding and when users change jobs within the organization.
Customer Privacy
If your organization has legal obligations to protect customer privacy, or if you collect personal or sensitive data about your customers, I recommend adding field-level security to protect their information and stay in compliance. You may have legitimate business reasons for collecting certain types of personal information, but not everyone in your organization needs access to it. Consider adding restrictions for viewing fields like Birthdate, Gender Assigned at Birth, Race/Ethnicity, and SSN/Tax ID.
Enable Auditing on Protected Fields
For additional oversight of certain sensitive fields, you can enable auditing in your system. When auditing is turned on for a table, then you can track changes to those fields and know who made those changes, and when they made them.
Do Not Use for Credit Card Numbers
As a rule, Encore does not recommend storing credit card numbers in your CRM system, even if the values are masked with field-level security. It does not offer enough protection for payment card industry (PCI) compliance, which mandates a very strict set of security requirements.
Work With Your Partner
The best practice in an implementation is for your Dynamics 365 CRM partner to set up your initial field level security settings and profiles, and also train your internal experts (system administrator, etc.) to use these tools after go-live. Usually, discussions about security role and field-level security requirements begin in the Analysis phase of the project, with all elements of the security model firmly in place before the User Acceptance Testing (UAT) phase begins. UAT should include test scenarios for each field security profile and related security roles to ensure the model works the way it is supposed to and that there are no unintended consequences.
At Encore, we enjoy solving tough Dynamics 365-related problems for our clients, and we love to educate all Dynamics 365 users on how to work faster and better in their systems. If you’re looking for a Dynamics 365 CRM Partner to provide support, training, integrations, or implementations with Dynamics 365 and the rest of the Microsoft stack, please contact us. We’d love to help.
Author
