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.

clip_image001

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

image

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.

image

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

image

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?

image

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.

image

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:

image

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.

Tips

  • 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

https://msdn.microsoft.com/en-gb/library/gg309608.aspx

Enhanced Field-level Security Features for CRM 2015

https://www.powerobjects.com/2015/09/15/enhanced-field-level-security-features-for-crm-2015/

CRM 2013 – How to set up Field Level Security

https://crmbusiness.wordpress.com/2014/05/22/crm-2013-how-to-set-up-field-level-security/

Share this Article

Search Articles

Filter Articles

CRM Tech DocMan

Recent Articles

Dynamics 365 Marketing vs ClickDimensions It’s time to pause, reflect and acknowledge a new era of inclusivity and collaboration. Part 2 - How to get the most from a Technology Expert – Asset Management Hub Property & Asset Management Hub Part 1 – Balancing CRM and Asset Management Scopes - Asset Management Hub Creating a Multi-Lingual PowerApps Portal How to Set Up a Microsoft Teams Site Using DocDrive365 Microsoft Teams - Adding a Microsoft Teams URL to a Dynamics Appointment Dynamics 365 Marketing – Customer Voice Survey Not Appearing In Emails? Using SQL Management Studio to connect to the Dynamics DB Calling a Power Platform AI Builder Model via oData How to use DocDrive365 to integrate permissions between Business Units in Dynamics with Sites in SharePoint Getting started with the Power Platform AI Builder. Power Apps Portal Information Hub DocDrive365 Security: Day One - Getting Started with Dynamics to SharePoint Permissions Part 5 - Power Apps Portals: How To Connect Azure B2C With Linked-In Part 4 – Power Apps Portals: Styling Azure B2C for Power Apps Portals The 3 Phases for Using Multi-Select Option Sets in Flow with Microsoft Forms Part 3 – PowerApps Portals: Azure B2C and Power Apps Portals – User Flow for Signup and Signin Part 2 - Power Apps Portals: New Application Registration in Azure B2C for our Power Apps Portal Part 1 – Power Apps Portals: Creating a New Azure AD B2C Tenant The Automation Bot: Launching Contextual Flow from Teams Creating a New Bot for Teams Debugging your Teams Bot using Ngrok Adding a Microsoft Teams URL to a Dynamics Appointment
Contact Us

Want expert advice or a demo?

Get in touch now and see how we can help your business grow.

  • Name
  • Email Address
  • Phone Number
 
Close

Understanding Your Challenges

Our strong understanding of CRM and emerging technologies within the Microsoft environment means we deliver the right solutions for you.

Proven Real-World Solutions

As a leader in the field of Dynamics solutions, our pedigree developing and delivering real-world solutions is unsurpassed.

Long Term Support

We provide support beyond our design, implementation and 'go-live' delivery using Sprints and continual updates to our AppSource apps.

CRMCS | Design by Thinktank Marketing | Citrus-Lime Limited

To improve your experience today and in the future, this site uses cookies. Read our full Privacy Policy & Cookie information here I Understand