Field-level security is organization-wide feature that applies to all data access requests including the following requests from within a client application (such as web browser, mobile client, or Microsoft Dynamics 365 for Outlook), web service calls and Reporting.
Due to the similar terminologies there has been a confusion between Field-level data encryption and Field level security and sometimes some customers think that there is an extra encryption when using Field level security. As you know in Dataverse, 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, Microsoft introduced the Field-level security to control their access.
Field-level security is available for most of out-of-box fields and custom fields and is managed by the security profiles. To implement field-level security, a system administrator performs the following tasks.
- Enable field security on one or more fields for a given entity.
- Associate one more security profiles to grant the appropriate access to specific users or teams.
Security Profiles can be configured to grant a combination of the following 3 permissions at the field level:
- Read (read-only access to field data)
- Create (users or teams can add data to this field when creating a record)
- Update (users or teams can update the field’s data after it has been created)
Field Level Security helpsto limit the access to group of users but do not encrypt the corresponding fields with the custom Data Encryption key.
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 field definition from Solution Explorer. In Solution Explorer expand Entities, expand the entity that you want, select Fields, and then open the field that you want. If Enable can be selected, the field can be enabled for field security.
Although most attributes can be secured, there are system attributes, such as IDs, timestamps, and record tracking attributes, that can’t. Below are a few examples of attributes that can’t be enabled for field security.
- firstname, lastname, fullname
- ownerid, processid, stageid, accountid, contactid
- createdby, modifiedby, OwningTeam, OwningUser
- createdon, EntityImage_Timestamp, modifiedon, OnHoldTime, overriddencreatedon
- statecode, statuscode, etc…
Example for restricting the mobile phone
Imagine your company’s policy is that sales members should have different levels of access to contact email address as described here.
Vice presidents : Full. Can create, update, and view email addresses for contacts.
Sales Managers : Read-only. Can only view email addresses for contacts.
Salespersons and all other users : None. Cannot create, update or view email addresses for contacts.
To restrict this field, you can define 2 Fields Security profiles VP access contact email address and SalesManager access contact email address and Enable the Field Security attribute of the EmailAddress select Enable.
In conclusion, using Field Level Security provides several benefits in terms of providing more precise control over the data that specific users can access and view. However, there is a performance impact associated with it, and the more extensively the feature is used in an implementation, the greater the impact on performances.