Support Portal ContactGet in touch

Field Level Security in Dynamics CRM

   Words by CRM Consultancy

   on 06/01/2016 16:12:15

Prior to CRM 2011, one of the most requested developments was the ability to lock a particular user or group of users from a particular field.

To combat this requirement, Microsoft introduced true Field Level Security back with CRM 2011 and this has since formed part of the core platform in CRM 2013, 2015 and now 2016.

Business Scenario

We want to prevent certain users to view a Company’s Billing Addresses but be prevented from modifying Billing Addresses, whilst still being able to modify the Company’s Correspondence Address.


Solution Design

We would avoid using Security Roles to implement this requirement, as this would potentially block a User from modifying any Address or any Company record in CRM.

As we want to allow edits to the main Correspondence Address, but block edits to the Billing Address (address2 in CRM speak!), we would opt to use Field Security to restrict access to the second address fields.

How we do it

1. If we do not already have a Solution in Dynamics to hold our Security Settings, we should create a new Solution that we can use to track any new or amended Security Roles or Field Security Profiles.  We can then open this solution and perform the following steps.

2. First of all, we will need to specify which fields we want to enable Field-Level Security for.  This is done within the Fields Area for the CRM Entity involved – and so we need to add the Customer Account entity into our solution and then access the list of Fields available for this Entity.

From here, we can edit any particular field to enable Field-Level Security for that Field.

NOTE: Unfortunately we are not able to do this in bulk using the native interface for Dynamics and so need to do this one field at a time.

TIP: Avoid doing one field at a time, but instead open a range of new browser windows, one for each field


3. Changes to Field Level Security only take place after being Published, so we need to Publish our Solution before continuing.

4. Once we have our Fields enabled for Field Level Security and Published, we can then setup a Field Security Profile to govern who has access to each field.


5. In our new Field Security Profile we then determine the Permission Level over each Security Enabled Field:


Each field can then allow either:

Read Permission – are users associated with this Field Level Security Profile allowed to view the contents of this field?

Write Permission – similarly can users edit the contents of this field?

Create Permissions – slightly more outlandish, but can users set the initial value of this field when creating a new record?


So in our example of restricting access to all the Address 2 fields, we would configure our Profile with YES for the Read Permission, but NO for Write and Create Permissions – implementing a ‘look but don’t touch’ approach to the fields.

6. Once we have defined the rules our Field Level Security Profile will enforce, we can then apply this Profile to various Users or Teams in CRM.


We can choose to apply this profile to either specific Users, or to whichever Users are in a particular Team to give us a more flexible approach.

7. We can then view the Customer Account Form in CRM to see our new Security in action:


At this point, any users using the restricted Field Security Profile will have locked-down Read-Only permissions on the Fields.

Whereas any users using the enhanced Field Security Profile will have normal Read/Write access to the Field.

Regardless of Permission Level, the Fields will be shown with the Key Icon to indicate that these Fields have Field Level Security Enabled.

8. If the ‘Allow Read’ permission to set to NO, this will remove access to the Field in Views and Advanced Finds as well as the Form.  This does NOT remove access to the Field in developed SSRS / SQL Reports – any logic for field restrictions must also be built into these developed reports as part of the report, as the CRM Platform does not enforce Field Level Security outside CRM in SQL Reports.

9. However if the ‘Allow Read’ or ‘Allow Update’ permissions are set to NO, this also blocks these permissions for any automated logic that is running as this User.  So any Workflows or developed Plugins which need to read or update a particular field will fail with a security error!

10. This differs from making the field Read-Only on the Form – in that the Form Design is modifying the User Interface only, whereas Field Level Security is imposing a hard security restriction.  So for example, a Workflow or Plugin can still update a Field which is Read-Only on the Form, whereas Field Level Security will prevent any this update if the user does not have ‘Allow Read’ permission.


  • Security Roles implement record-level security – i.e. can I see a record, can I edit a record.  Field Security Profiles implement field-level security on a field by field basis.  Record Level Security always has a higher priority over Field Level Security!
  • Users with the System Administrator Security Role override the Field Level Security configuration and automatically have Read+Write+Create permissions on the Fields involved
  • Certain System Fields cannot be enabled for Field-Level Security, and this may vary depending on the version of Dynamics CRM involved – for example the Address2 fields in CRM 2011 cannot be enabled for Field Level Security, whereas Address2 can be enabled in CRM 2015
  • As soon as enable Field Level Security on a Field, this immediately takes away access to the Field for all Non-System Admin Users and so should be done carefully!  (or ideally in a separate Development or Test Environment and then the Security Profiles deployed to Live)

Best Practise

  • Our advise is always to start with the most generous level of security and then add additional security rules (whether these be Record-Level or Field-Level) as required; so give us the smallest and simplest number of security rules in place in the solution.  This keeps to the KISS principle of keeping the solution simple.
  • Always use Teams over specific Users to drive Field Security Profiles, this makes User Management more simple for CRM Administrators to handle New Starters and Leavers.

Further Reading

How field security can be used to control access to field values in Microsoft Dynamics CRM

Enhanced Field-level Security Features for CRM 2015

CRM 2013 – How to set up Field Level Security

Share this Article

Search Articles

Filter Articles

CRM Tech DocMan

Recent Articles

CRMCS Quick Start Guide: How To Produce a Microsoft Teams Live Event Dynamics 365 Marketing: Lead Scoring and Sales Acceptance Designing and Developing Microsoft Power Apps Portals Thank You for Attending CRMCS’ Webinar - Achieving B2B sales excellence with Dynamics 365 & Microsoft Teams Thank You for Attending Our Webinar - Achieving B2B sales excellence with Dynamics 365 & Microsoft Teams Webinar: Discover How CRMCS Have United Dynamics 365, SharePoint and Microsoft Teams To Create Sales Excellence Ignite your workflow by adding DocDrive365 to Office 365 The CRMCS guide to everything you need to know about integrating Teams with Dynamics 365 Saving Time By Keeping Documents In One Place TDE Database Encryption with On Premise Dynamics The Key to Successful Compliance in 2020 Part 2: Let’s get GDPR Compliant with Microsoft Power Automate Top 3 Essential Tips for Remote Working Dynamics 365 Marketing: Top 5 Best Features Dynamics Day in the Life - Puma Investments Can you use Teams to amplify collaboration in Dynamics? Part 1: Using a Scheduled Power Automate to Trigger Expiry Date Reminders The secrets of successful document collaboration in Dynamics CRMCS launches new AppSource approved DocDrive365 Dynamics Day in the Life - Moneypenny Release Management Add the App to Dynamics DocDrive365 Security: Day One - Getting Started with Dynamics to SharePoint Permissions Building a New Scheduled Process using Flow
  • "Paul has made a real difference to how my team of 24 people record and store valuable customer data and sales opportunities. Highly recommended."

    James, Operations Director

  • "Understanding your business allows us to advise when to implement aspects of CRM and, likewise, when not to."

    Paul McQuillan, Managing Director

  • "Dynamics 365 and CRMCS have made a real lasting difference to our business, allowing us to replace older systems that were holding back our performance."

    Grahame, Chief Operating Officer

  • "James worked well with us to help connect CRM with Outlook and relate how this might benefit our team using CRM for Property Care."

    Natalie, Property Care Supervisor

  • "Matt was really good with helping us run User Testing on the new Compliance Module of our CRM System."

    Tom, Compliance Administrator

Prefer to go old-school?

Write to us using the below addresses.

Head Office
CRM Consultancy
61 Oxford Street
M1 6EQ

London Office
CRM Consultancy London
Grosvenor Avenue

Content © CRM Consultancy.