In this blog we show you how to create a build and a release pipeline in Azure DevOps that use one parameterized task group for deploying Azure Logic Apps and Functions to different environments.
Field-level security was introduced in Microsoft Dynamics CRM 2011 for custom fields. This gave the system administrator the ability to secure custom fields on a form to prevent Create, Read and Write privileges for selected users. However, this was available only for custom fields. For CRM 2015, the Field Level Security features have been enhanced. In today's blog, we will go over exactly what those enhancements are and how they can benefit your organization.
The security demands of CRM can vary significantly depending on Industry. Based on your organization's security requirements, CRM 2015 Field Level Security's enhanced features allow you to build complex security models easily.
In Microsoft Dynamics CRM 2015, field-level security now has these enhanced features:
1. Field-level Security will now allow System Administrators and System Customizers to secure out-of-the-box fields along with custom fields.
To identity the attributes which support field-level security, click on any entity in the customizations area and navigate to the Fields area of the entity.
The Field Security column helps to quickly identity the behavior of the field towards field-level security by using the statuses below:
However, there are a few entities such as Discounts, Price Lists, etc. that are not customizable and do not support field-level security on their fields. To see which entities are not customizable, navigate to the Discount entity and check the fields. The Field Security for those fields will be set to Not Applicable as the system does not allow field-level security for these entities.
2. Securing Personal Identifiable Information (PII) that you store on the Contact record (Address, Phone Number, etc.) is now feasible. By using field-level security on address fields, you can restrict a group of users or teams from reading and updating the field values based on the requirement which in turn increases the integrity and security of the contact record.
There is one restriction regarding Boolean attributes to mention here. Since it is necessary to read the result of a Boolean attribute to be either Yes/No or True/False, you will not have the ability to restrict read access. You will only have the ability to restrict create and update access.
Let's take a look at a possible scenario. Dan is a Senior Manager who has access to all of the accounts in the company. Mike is Dan's assistant. Mike attends client calls on behalf of Dan and is responsible for updating the respective Account record(s) with call details. Mike should have access to the Account records, but he should not have access to view any Personal Identification Information such as their Address.
In the above scenario, Mike will have Read privileges for Accounts, and by using field-level security, we can also restrict his access to certain fields on Account records. Let's take a look at how we can achieve this.
When Dan logs into CRM and opens up an Account, he can currently view all of the information as seen below.
In order to enable field-level security to restrict Mike from viewing Account address information, navigate to the Account entity in the customizations area. Since Address is a composite field, make sure field-level security is enabled for all the fields related to the Address.
Example: Open Address 1: Street 1 and enable Field Security. Save and Publish the changes.
Repeat the above step for all the address related fields you wish to restrict access to such as Street 1, Street 2, Street 3, City, State, Country, Zip code, etc.
Next, a Security Profile needs to be created which will define the permissions required to restrict users and teams. In order to create a new Security Profile, first navigate to Settings -> Security -> and click Field Security Profiles.
Click New to create a new Field Security Profile.
Provide the name and description of the Security Profile and Save the record. In order to specify the permissions for the Security profile, click Field Permissions on the left navigation pane.
Open each field and specify permissions accordingly.
The next step is to add Mike to the Security Profile. Click on User (you can also add teams per the requirement) on the left navigation pane. Click the Add button, search for Mike and then add him to the Security Profile.
Now, when Mike logs into CRM and opens Account records, the address field(s) are restricted from his viewing, as shown in the example below.
We hope you found this information on the enhanced Field Level Security features helpful! For more information about Microsoft Dynamics 2015 check out our website.