How to Use Field Security Profiles in Microsoft Dynamics CRM 2015
CRM field level security restricts access to record fields which might contain sensitive business data which should only be seen by authorised individuals.
This can prove helpful in several scenarios, for example restricting access to a password field on an account form, or credit card / bank details stored on a contact record which should only been seen by users who are granted the highest level of CRM permission.
Until recently, field security was only available for custom fields on custom CRM entities.
With the release of Dynamics CRM 2015, these controls are enhanced and can now also be set on default fields. Also, they can now be applied to most out of the box entities including contacts and accounts.
How to set field level security
Let’s use the example of restricting access to user ‘David Brettell’ on a field named ‘Password’ that appears on the account entity form.
In the customization page for the account entity, a new field can be added named ‘Password’. Below these name fields the field security control will be set to Enable:
To complete, save and publish these changes.
The next step is to define a Field Security Profile (FSP).
In CRM go to Settings > Security > Field Security Profiles and create a new profile.
In the example below we’ve named this profile ‘Restrict Account Password’.
Once saved the navigation pane is enabled so click ‘Field permissions’ which enables a user or team security control to be applied to the new field we’ve defined.
To complete this we've clicked on the new password field and adjusted the permissions for read, update and create are set to 'No':
Once these permissions have been configured we can select which users and or team(s) the FSP will apply to, i.e. which users and teams will be restricted from accessing this field.
In this example we’ll withhold permission for one user account named David Brettell:
When David opens an account record he’ll see the password field that appears as follows:
The key mark indicates password field is covered under a field security profile while the lock confirms this user does not have update access.
In line with the rule we've set the hidden 'starred' content demonstrates that read permission on this field is withheld for this CRM user.
More about Field Security Profiles
System administrators by default have full permission on all fields which are covered under a FSP.
If the same user or team is configured under several FSP's which result in different permissions for a specific field the maximum permission would apply.
For example, if in one FSP a user does not have read access to a password field but in another FSP they are granted read-only permission to this field. In this scenario the maximum permission will apply (e.g. read account password).
Special care should be taken when considering best practices for field security on CRM calculated fields.
These rules should also include each of the fields that are used in the calculation under same field security profile.
Also, if you apply field level security rules to a composite address field you'll need to make sure all of supporting address line fields are included in the field security profile.
Field security is not limited to restricting access of fields on record form only but that also implies restriction on data access requests within the client application, web service calls using SDK and data display on report.
We hope you find these updated field level security processes offer you greater flexibility in managing user access to your CRM database and safeguarding your data.
Please don't hesitate to contact any of the team at Preact if you want to find out more about configuring CRM field level security or to discuss any of the latest Microsoft Dynamics improvements.