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

CRM 2013 – How to set up Field Level Security

Author

Write A Comment