Field level security

Applies To: Dynamics CRM 2015

Record-level permissions are granted at the entity level, but you may have certain fields associated with an entity that contain data that is more sensitive than the other fields. For these situations, you use field level security to control access to specific fields.

The scope of the field level security is organization wide and applies to all data access requests including the following:

• Data access requests from within a client application, such as web browser, mobile client, or Microsoft Dynamics CRM for Outlook.

• Web service calls using CRM SDK (for use in plug-ins, custom workflow activities and custom code)

• Reporting (using Filtered Views)

In This Topic

Overview of field level security

Example for restricting the mobile phone field for the Contact entity

Which fields can be secured?

Best practices when you use field security

Overview of field level security

In Microsoft Dynamics CRM 2015, field level security is now available for the default fields on most out-of-box entities, custom fields, and custom fields on custom entities. Field level security is managed by the security profiles. To implement field level security, a system administrator performs the following tasks.

1. Enable field security on one or more fields for a given entity.

2. Associate one more existing security profiles, or create one or more new security profiles to grant the appropriate access to specific users or teams.

A security profile determines the following:

• Permissions to the secure fields

• Users and Teams

A security profile can be configured to grant user or team members the following permissions at the field level:

• Read. Read-only access to the field’s data.

• Create. Users or teams in this profile can add data to this field when creating a record.

• Update. Users or teams in this profile can update the field’s data after it has been created.

A combination of these three permissions can be configured to determine the user privileges for a specific data field.

Example for restricting the mobile phone field for the Contact entity

Imagine you company’s policy is that sales members should have no different levels of access to contact mobile phone numbers as described here.

To restrict this field, you would perform the following tasks.

Secure the field.

1. Go to Settings > Customizations.

2. Choose Customize the System.

3. Choose Entities > Contact > Fields.

4. Choose mobilephone, choose Edit.

5. Next to Field Security, choose Enable, choose Save and Close.

6. Publish the customization.

Configure the security profiles.

1. Create the field security profile for sales managers.

   1. Go to Settings > Security.

   2. Choose Field Security Profiles.

   3. Choose New, enter a name, such as Sales Manager access contact mobile phone, and click Save.

   4. Choose Users, choose Add, select the users that you want to grant read access to the mobile phone number on the contact form, and then choose Add.

      Tip

      Instead of adding each user, create one or more teams that include all users that you want to grant read access.

   5. Choose Field Permissions, choose mobilephone, choose Edit, select Yes next to Allow Read, and then click OK.

2. Create the field security profiles for vice presidents.

   1. Choose New, enter a name, such as VP access contact mobile phone, and choose Save.

   2. Choose Users, choose Add, select the users that you want to grant full access to the mobile phone number on the contact form, and then choose Add.

   3. Choose Field Permissions, choose mobilephone, choose Edit, select Yes next to Allow Read, Allow Update, and Allow Create, and then click OK.

3. Choose Save and Close.

Any CRM users not defined in the previously created field security profiles will not have access to the mobile phone field on contact forms or views. The field value displays ********, indicating that the field is secured.

Which fields can be secured?

Every field in the system contains a setting for whether field security is allowed. You can view this in the Customizations area of the web application. There are thousands of attributes that can be secured, so there are two easier ways to look for this information. To view the entity metadata for your organization, install the Metadata Browser solution described in MSDN: Browse the Metadata for Your Organization. You can also view the metadata for an uncustomized organization in the Microsoft Office Excel file called EntityMetadata.xlsx included in the top-level folder of the SDK. Download the Microsoft Dynamics CRM SDK package.

Best practices when you use field security

When you use calculated fields that include a field that is secured, data may be displayed in the calculated field to users that don’t have permission to the secured field. In this situation, both the original field and the calculated field should be secured.

Some data, such as addresses, are actually made up of multiple fields. Therefore, to completely secure data that includes multiple fields, such as addresses, you must secure and configure the appropriate field security profiles on multiple fields for the entity. For example, to completely secure addresses for an entity, secure all relevant address fields, such as address_line1, address_line2, address_line3, address1_city, address1_composite, and so on.

When a system administrator implements security for particular fields or records, it can affect the data that’s synchronized between Microsoft Dynamics CRM and Outlook, including the inability to push data to the user running CRM for Outlook. Before you secure a field, consider how it may affect your users that are running CRM for Outlook. More information: How field security affects synchronization between CRM and CRM for Outlook

See Also

Video: Field Level Security in Microsoft Dynamics CRM 2015
Help & Training: Create a field security profile
Help & Training: Add or remove security from a field

© 2016 Microsoft Corporation. All rights reserved. Copyright