I’ve written in the past about Least Privilege Security in D365FO but one aspect I haven’t covered yet is the process of setting up field level security in D365FO.
In D365FO, entry point security has changed slightly from AX 2012 and has simplified security by allowing menu item access to drive data source access. I’ve written about this in detail in a previous post.
But if you want to be more granular than allowing access to a particular form then field level security is the way to go. The idea of field level security is to restrict a users access to individual fields on a form.
How to Determine Which Table Field Corresponds to the User Interface Element You Want To Permit/Restrict
The first step in performing field level security is to determine the table and field you need to permit/restrict. The easiest way to do this is to find the field in the user interface, right click on it go to Form Information -> then click on the Form Name option, this will cause the Form Information dialog to appear on the right hand side of the screen. In this dialog will be an Administration heading with the Data Source and Data Field parameters. The Data Source and Data Field parameters correspond to the table and field that you would have place field level security on.
Scenario 1 – Read access to a vendor but user should not be able to see the Bank Account field
When trying to remove access to particular fields on a form, the easiest option is to set those fields to No Access/Deny (depending on if you set it from the AOT or user interface). This deny is an explicit deny which means it will override any other grants this user has to this table field combination.
So for example if we have a privilege that has Read access to the VendTableListPage, they would see something like this with the Bank Account field (12345) being shown under Payment tab:
To remove Read access to the Bank Account field, find the VendTableListPage entry point in the security layer we are modifying and under the Data Sources we add the VendTable table and then the BankAccount field and set the field to have No Access.
Now when we look at this again you can see the user has no visibility to see the Bank Account field at all.
Scenario 2 – Read access to Vendor but Update access to Credit Limit
This scenario was tougher to figure out as my initial thought was to set Read permissions to the VendTableListPage menu item, Read access to the VendTable, and Update permission to the CreditMax field but this turned out to make all the fields on the form read only. To be able to make the form editable in any way I had to set the data source to an Update permission. But by doing this it also made every other field on the Vendor editable, so to alleviate this you have to set Read permission to all other fields. (In the example below I only did a few fields on the VendTable for testing)
So in my example I set Update permission to the CreditMax field, and Read permissions to the CreditRating, BidOnly, OneTimeVendor, LocallyOwned, and Currency fields.
In the example above you can see that the Credit Limit field is editable but the Credit Rating field is not.
It is tough to see in the screenshot but there are some differences under the Vendor Profile section as well. The Bid Only, One-Time Suppiler, and Locally Owned checkbox fields are not able to be edited while the other options are able to be edited.
Multiple data sources on a single form
You may notice in the example above, that there are some fields on the form that do not exist on the VendTable table. Since these fields exist on another table the security for them default back to the entry point security (in this case the security on the VendTableListPage menu item). Because of this, we want the access to the entry point to be the most restrictive possible as we don’t want to inadvertently grant more access to fields on the form when setting up field level security.
Field Level Security Overview
Setting up field level security can be a time consuming process, especially on forms that have multiple data sources and on tables that have a large number of fields. But it can be the best way to permit/restrict a user to perform particular functions while keeping other data protected.
The process for this would be:
- Identify the table field combination you would like to restrict as well as the entry point (menu item) associated with it
- Set the security at the entry point as restrictive as possible
- Set the security at the table level as the least restrictive as needed
- For example, if you want to be able to update certain fields but not others, you would set Read permission to the entry point and Update permission at the table level
- Set field level security as needed
- By default, field security will match permission set at table level
- Need to set permissions on each table field that you want to be more restrictive than the access you set at the table level
- For example, if you want the user to not be able to update certain fields but not others you would need to set all fields that the user should not be able to update at a Read permission
Hopefully this walk through helps with understanding the field level security process, as always if you have any questions feel free to reach out!
