Looking for PowerObjects? Don’t worry, you’re in the right place! We’ve been part of HCL for several years, and we’ve now taken the final step in our acquisition journey: moving our website to the HCL domain. Nothing else is changing – we are still fanatically focused on Microsoft Business Applications!

PowerObjects Blog 

for Microsoft Business Applications

Enhanced Field-level Security Features for CRM 2015

Post Author: Joe D365 |

Field-level security was introduced in Microsoft Dynamics CRM 2011 for custom fields. This gave the system administrator the ability to secure custom fields on a form to prevent Create, Read and Write privileges for selected users. However, this was available only for custom fields. For CRM 2015, the Field Level Security features have been enhanced. In today's blog, we will go over exactly what those enhancements are and how they can benefit your organization.

The security demands of CRM can vary significantly depending on Industry. Based on your organization's security requirements, CRM 2015 Field Level Security's enhanced features allow you to build complex security models easily.

In Microsoft Dynamics CRM 2015, field-level security now has these enhanced features:

1. Field-level Security will now allow System Administrators and System Customizers to secure out-of-the-box fields along with custom fields.

To identity the attributes which support field-level security, click on any entity in the customizations area and navigate to the Fields area of the entity.


The Field Security column helps to quickly identity the behavior of the field towards field-level security by using the statuses below:

  • Disabled - Available for field-level security, but is presently not secured by an administrator
  • Not Applicable - Not valid for field-level security
  • Enabled – Attribute secured by an administrator

However, there are a few entities such as Discounts, Price Lists, etc. that are not customizable and do not support field-level security on their fields. To see which entities are not customizable, navigate to the Discount entity and check the fields. The Field Security for those fields will be set to Not Applicable as the system does not allow field-level security for these entities.


2. Securing Personal Identifiable Information (PII) that you store on the Contact record (Address, Phone Number, etc.) is now feasible. By using field-level security on address fields, you can restrict a group of users or teams from reading and updating the field values based on the requirement which in turn increases the integrity and security of the contact record.

There is one restriction regarding Boolean attributes to mention here. Since it is necessary to read the result of a Boolean attribute to be either Yes/No or True/False, you will not have the ability to restrict read access. You will only have the ability to restrict create and update access.

Let's take a look at a possible scenario. Dan is a Senior Manager who has access to all of the accounts in the company. Mike is Dan's assistant. Mike attends client calls on behalf of Dan and is responsible for updating the respective Account record(s) with call details. Mike should have access to the Account records, but he should not have access to view any Personal Identification Information such as their Address.

In the above scenario, Mike will have Read privileges for Accounts, and by using field-level security, we can also restrict his access to certain fields on Account records. Let's take a look at how we can achieve this.

When Dan logs into CRM and opens up an Account, he can currently view all of the information as seen below.


In order to enable field-level security to restrict Mike from viewing Account address information, navigate to the Account entity in the customizations area. Since Address is a composite field, make sure field-level security is enabled for all the fields related to the Address.

Example: Open Address 1: Street 1 and enable Field Security. Save and Publish the changes.

Repeat the above step for all the address related fields you wish to restrict access to such as Street 1, Street 2, Street 3, City, State, Country, Zip code, etc.

Next, a Security Profile needs to be created which will define the permissions required to restrict users and teams. In order to create a new Security Profile, first navigate to Settings -> Security -> and click Field Security Profiles.

Click New to create a new Field Security Profile.

Provide the name and description of the Security Profile and Save the record. In order to specify the permissions for the Security profile, click Field Permissions on the left navigation pane.

Open each field and specify permissions accordingly.

The next step is to add Mike to the Security Profile. Click on User (you can also add teams per the requirement) on the left navigation pane. Click the Add button, search for Mike and then add him to the Security Profile.

Now, when Mike logs into CRM and opens Account records, the address field(s) are restricted from his viewing, as shown in the example below.

We hope you found this information on the enhanced Field Level Security features helpful! For more information about Microsoft Dynamics 2015 check out our website.

Happy CRM'ing!

By Joe D365
Joe D365 is a Microsoft Dynamics 365 superhero who runs on pure Dynamics adrenaline. As the face of PowerObjects, Joe D365’s mission is to reveal innovative ways to use Dynamics 365 and bring the application to more businesses and organizations around the world.

2 comments on “Enhanced Field-level Security Features for CRM 2015”

  1. I have a user who is in two different field security profiles. In one they are restricted and cannot access "Field A" but in another profile they have been given permission to access "Field A" yet they cannot access the field. Shouldn't the profile which allows access be dominant?

  2. Hi Joe,

    Thanks for the above post.

    Just a quick question - The above is applicable to the users only who are added into the newly created Field Security Role. For example, In a team of 7 users, requirements is to restrict 4 users update privilege and leave the rest with read/write/update access. I have added the new profile and added the users into it but when implemented other users can't see the information.

    Issue with original backup - When I removed the role from the solution it has removed the value for those two fields from CRM. I think it's a big drawback with Field Security Permissions. Can you please verify this.

PowerObjects Recommends