How field security can be used to control access to field values in Microsoft Dynamics 365

 

Updated: November 29, 2016

Applies To: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

In Microsoft Dynamics 365 and Microsoft Dynamics 365 (online), you use field-level security to restrict access to high business impact fields to specific users and teams. For example, you use this to enable only certain users to read or update the credit score for a customer. For this release, field-level security can be applied to both custom fields and many out-of-box (OOB) fields.

The following steps describe how to restrict access to a field:

  1. Enable field-level security for an attribute

  2. Create a field-level security profile

  3. Associate users or teams with the profile

  4. Add specific field permissions, such as Create, Update or Read for a specific attribute to the profile

The following diagram shows the interaction between role-based security, record-based security, and field-level security.

Role-based compared to field-level security

Role-based security lets you see a specific entity type, record-based security lets you see individual records, and field-level security lets you see specific fields.

Video: Field Level Security in Microsoft Dynamics CRM 2015

To see which attributes can be secured, you can query the entity metadata for the following properties:

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 Browse the metadata for your organization. You can also view the metadata for an uncustomized organization in the Excel file called EntityMetadata.xlsx included in the top-level folder of the SDK download.

There are a few additional rules that apply to certain attribute data types:

  • Boolean attributes can be secured for create and update operations but not for read.

  • Option set attributes can be secured for create, update, and read when a default value is unspecified.

The System Administrator field security profile gives full access to all secured fields in Microsoft Dynamics 365. By default, all users who have the System Administrator security role have this profile. This profile is system managed and can’t be updated or deleted.

When you call the Retrieve or RetrieveMultiple methods or messages, Microsoft Dynamics 365 evaluates if the caller and the impersonated user have access to each retrieved record (this is the regular security process) and each secured field. The call does not throw an exception if the criteria contain secured fields for which the caller does not have access. Instead, null values are returned for secured fields if they are part of the output column set.

The following describes more about the retrieve multiple behaviors for secured fields.

If the caller (or impersonated user) does not have read access to the secured fields that are included in a column set, the value returns as null. You cannot tell the difference between a returned null value caused by no data or caused by insufficient access.

If the caller (or impersonated user) does not have access to the secured fields that are included in the filter criteria, the field value is substituted with null during the evaluation of the filter.

In the following table, the caller has access to all attributes except those indicated with an asterisk (*).

Record Number

Value of the Name attribute

Value of the Description attribute

Value of the Can Be Contacted attribute

1

A

AAA

True

2

B

BBB

False

3

C

CCC

True*

4

D

DDD

Null

5*

E*

EEE*

Null*

When the filter is CanbeContacted == True, only record one is returned.

When the filter is IsNULL (CanbeContacted), records 3 and 4 are returned. Since record 3 is hidden from the user, it is treated as null during condition evaluation and will be evaluated as True for ISNull.

Secured values are substituted with a null value, so normal SQL aggregation behavior applies.

If the caller (or impersonated user) does not have access to the attribute used for grouping, the value is treated as null and the results are grouped together with all null values.

In the following example, the caller has access to some attributes. Bold indicates no access to attributes, also indicated with *. Italics indicate a record for which the caller does not have read access, also indicated with **.

Name

Description

Number of orders

State

A

AAA

1

WA

B

BBB

4

WA

C

CCC

4

CA

D**

DDD**

3**

MA**

E

EEE

0

CA

F

FFF

0

WA*

G

GGG

2

CA*

Select State, Total(orders) Group by (STATE) results in the following:

WA–5

CA–4

null–2

If the caller (or impersonated user) does not have access to secured fields that are included in an order by condition, the values will be treated as if they are null.

In the following example, the caller has access to attributes that are in plain text. Bold indicates no access to attributes, also indicated with an asterisk (*). Italics indicate a record for which the caller does not have read access, also indicated with **.

Name

Description

CanbeContacted

A

AAA

True

B

BBB

False

C

CCC*

True*

D

DDD

Null

E

EEE*

Null*

F**

FFF**

True**

G

Null

True

Select Name order by Description ascending results in the following:

{G,E,C},A, B, D, will be returned.

A programmer may build a client that uses Create and Update methods that interact with secured fields. When you call the Create or Update method, passing data for secured fields and the caller does not have sufficient permissions, an exception is thrown.

A user with access to a secured field in a record can share it with another user or team. The user can only give the access that they have on the record. For example, to share the record and grant Update privileges, the user must have update privileges.

You can share a secured field on a particular record with Read and/or Update with a security principal (user or team).  The user or team members with whom the record was shared now have that type of secured field access only on the shared secured fields on only that particular record, even if the user or team member to whom it was shared does not have a field security profile that gives them access.

An administrator secures a number of fields for access in the application and wants the fields not to be available in reports. This allows for maintaining the same set of reports for all users. Filtered views will not return data for the secured fields if the calling user does not have authorization for the fields. When no field security is applied for any of the view’s attributes, the filtered views return complete data.

If you are using Microsoft Dynamics 365 for Microsoft Office Outlook with Offline Access, only the secured field values that you have access to replicate into the offline database. If you don’t have access to the data, it is not saved offline.

Microsoft Dynamics 365

© 2016 Microsoft. All rights reserved. Copyright

Community Additions

Show: