web
You’re offline. This is a read only version of the page.
close
Skip to main content
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Blogs / Dynamix Academy / What is Field level securit...

What is Field level security in Dynamics 365 / CRM?

Views (41)
Abhishek Dhoriya Profile Picture Abhishek Dhoriya 1,013

Hello everyone, welcome back to Microsoft Dynamics CRM / 365 Tutorial for beginners series. It is yet another Dynamics 365 CRM Features explanation article by Dynamix Academy. In this article we will learn everything about field level security in Dynamics 365 / CRM as well as Field security profile in MS Dynamics CRM / 365.

  1. Feature Overview – Dynamics CRM / 36 Field level security
    • What is Field Level Security in Microsoft Dynamics CRM / 365?
  2. History of Field Level Security in Dynamics CRM / 365
    • History of Field Level Security
  3. Major Changes in Microsoft Dynamics CRM field security
    • What were the major changes in Field Level Security till today?
  4. Detailed Feature Explanation – Microsoft Dynamics CRM / 365 field security
    • How to Configure Field Security Profiles in Dynamics 365?
    • How do secured fields behave under various situations (Retrieve, RetrieveMultiple, Create, Update etc.)?
  5. Future Roadmap of Field level security in MS Dynamics CRM / 365
    • Major Announcements

What is Field Level Security in Microsoft Dynamics CRM / 365?

  • Dynamics 365 for Customer Engagement provides a security model that protects data integrity and privacy and supports efficient data access and collaboration. 
    • Role-based security lets you see records of a specific entity type.
    • Record-based security lets you see individual records.
    • Field-level security lets you see specific fields.
  • In Dynamics 365 Customer Engagement, 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 or some highly sensitive data like PII or Health Related or Monetary data.
  • Field Level Security in Microsoft Dynamics CRM allows you to expand your security model beyond entities to include specific fields.
  • You cannot secure fields as part of your typical security role setup. It’s a completely separate process. Setting up field security is a two-part process:
    1. Enable your field for Field Security
    2. Set up a Field Security Profile to define the privileges granted to your user(s) and/or team(s)

History of microsoft dynamics crm field level security 

  • Field level security was introduced with Microsoft Dynamics CRM 2011.
  • Before FLS was introduced, the only way to hide sensitive data was to hide it on the form.
    • Limitations
      • Anyone can view this data form advanced find
      • Through Custom web service call/Code
      • Even through Data Export, Offline Sync, Reports, etc.
      • And in SQL database from filtered views (in case of ON-PREMISE deployment)
  • Field-level Security allows certain fields to be protected
  • Robust and enforced at Global Level
    • Applies to advanced find, web service calls, offline sync, reports, and even in SQL Queries (FilteredViews by Default) etc.….. Everywhere
  • When it was launched, it Can only be applied to Custom Fields of any Entity.

Major Changes in Field Level Security of Microsoft Dynamics CRM / 365

Field level security was introduced with Microsoft Dynamics CRM 2011. Before that there were three versions of Microsoft Dynamics CRM released. In the below image, you can see the Major Changes in Field Level Security of Dynamics CRM / 365.

Dynamics CRM field level security quicksight
  • Microsoft CRM 1.0
    • Not Applicable
  • Microsoft Dynamics CRM 3.0
    • Not Applicable
  • Microsoft Dynamics CRM 4.0
    • Not Applicable
  • Microsoft Dynamics CRM 2011
    • Introduced
    • It can be applied to Custom Fields only.
  • Microsoft Dynamics CRM 2013
    • No Change
  • Microsoft Dynamics CRM 2015
    • Enhanced
    • Now can be applied to system Fields as well
  • Microsoft Dynamics CRM 2016
    • No Change
  • Microsoft Dynamics 365
    • No Change

Detailed Explanation of Field Level Security

How to Configure Field Security Profiles in Dynamics 365?

  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 and field-level security.
Dynamics CRM field level security tutorial

How do secured fields behave for create or update?

  • 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 if the caller does not have sufficient permissions, then an Insufficient Permission exception is thrown.

How do secured fields behave when records are shared?

  • 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.

How do secured fields behave for filtered views?

  • An administrator secures several 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.

How do secured fields behave for offline synchronization?

  • If you are using 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.

How do secured fields behave for Retrieve and RetrieveMultiple?

  • When you call the Retrieve or RetrieveMultiple methods or messages, Dynamics 365 Customer Engagement (on-premises) 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 when.
    • a secured attribute is in the column set
    • a secured attribute is in the filter condition
    • aggregating on secured attributes
    • grouping on secured attributes
    • ordering on secured attributes

When a secured attribute is in the column set

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.

When a secured attribute is in the filter condition

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.

When aggregating on secured attributes

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

When grouping on secured attributes

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.

When ordering on secured attributes

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.

Also, find More on Dynamix Academy :

You can also watch our Videos on playlist:

Let’s Connect:

The post What is Field level security in Dynamics 365 / CRM? appeared first on Dynamix Academy.

Comments

*This post is locked for comments