{"id":191,"date":"2022-01-06T11:34:57","date_gmt":"2022-01-06T11:34:57","guid":{"rendered":"https:\/\/blog.citrus-lime.com\/crmc\/?p=191"},"modified":"2022-01-06T11:34:57","modified_gmt":"2022-01-06T11:34:57","slug":"field-level-security-in-dynamics-crm","status":"publish","type":"post","link":"https:\/\/blog.citrus-lime.com\/crmc\/field-level-security-in-dynamics-crm\/","title":{"rendered":"Field Level Security in Dynamics CRM"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Business Scenario<\/h3>\n\n\n\n

We want to prevent certain users to view a Company\u2019s Billing Addresses but be prevented from modifying Billing Addresses, whilst still being able to modify the Company\u2019s Correspondence Address.<\/p>\n\n\n\n

\"clip_image001\"<\/figure>\n\n\n\n

Solution Design<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

How we do it<\/h3>\n\n\n\n

1.<\/strong> 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.<\/p>\n\n\n\n

2.<\/strong> 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 \u2013 and so we need to add the Customer Account entity into our solution and then access the list of Fields available for this Entity.<\/p>\n\n\n\n

From here, we can edit any particular field to enable Field-Level Security for that Field.<\/p>\n\n\n\n

NOTE: <\/strong>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.<\/p>\n\n\n\n

TIP: <\/strong>Avoid doing one field at a time, but instead open a range of new browser windows, one for each field<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

3.<\/strong> Changes to Field Level Security only take place after being Published, so we need to Publish our Solution before continuing.<\/p>\n\n\n\n

4.<\/strong> 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.<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

5.<\/strong> In our new Field Security Profile we then determine the Permission Level over each Security Enabled Field:<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

Each field can then allow either:<\/p>\n\n\n\n

Read Permission \u2013 <\/strong>are users associated with this Field Level Security Profile allowed to view the contents of this field?<\/p>\n\n\n\n

Write Permission \u2013 <\/strong>similarly can users edit the contents of this field?<\/p>\n\n\n\n

Create Permissions \u2013 <\/strong>slightly more outlandish, but can users set the initial value of this field when creating a new record?<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

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 \u2013 implementing a \u2018look but don\u2019t touch\u2019 approach to the fields.<\/p>\n\n\n\n

6.<\/strong> 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.<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

7.<\/strong> We can then view the Customer Account Form in CRM to see our new Security in action:<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

At this point, any users using the restricted Field Security Profile will have locked-down Read-Only permissions on the Fields.<\/p>\n\n\n\n

Whereas any users using the enhanced Field Security Profile will have normal Read\/Write access to the Field.<\/p>\n\n\n\n

Regardless of Permission Level, the Fields will be shown with the Key Icon<\/strong> to indicate that these Fields have Field Level Security Enabled.<\/p>\n\n\n\n

8.<\/strong> If the \u2018Allow Read\u2019 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 \u2013 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.<\/p>\n\n\n\n

9.<\/strong> However if the \u2018Allow Read\u2019 or \u2018Allow Update\u2019 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!<\/p>\n\n\n\n

10.<\/strong> This differs from making the field Read-Only on the Form \u2013 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 \u2018Allow Read\u2019 permission.<\/p>\n\n\n\n

Tips<\/h3>\n\n\n\n