*This blog post was co-authored by Sarah Guthrie a Senior Consultant at Protiviti*
Have you ever wondered how you can utilize security to restrict sensitive access in Dynamic 365FO? One way to accomplish this is by using field level security. This can serve as a valuable gatekeeper, ensuring that highly sensitive pages are restricted to only necessary editable fields. For out of the box fields, I have a previous blog post that explains this entire process.
At a high-level overview, you would follow these steps:
- Restrict menu items to “read-only”
- Grant full permissions to the table
- Limit all data sources that shouldn’t be editable to “read-only”
- Grant full permissions to the data source that requires editing
But what if we want to restrict a custom table field that is an extension of the base table, is that process any different?
Custom Table Field Configuration
Let’s say we want to extend the Released Product Details page with an additional field:
The InventTable is a datasource for the form, so let’s create a table field extension off of the InventTable:
And then we will create a form extension using the new custom table field we just created:
And now we can see the value being used on the form:
Custom Table Field Level Security
But now let’s say we want every other field on the form to be ‘Read Only’ and only allow updates to this field. When we go to assign the table field security we can see that the AMTest field is not visible on the Security Configuration form:
So how do we set up security for this table field? During a recent project, we were tasked with limiting access to the “Released Products” page to ‘read only’ while allowing only a single custom field to be edited. To our surprise, even though we could identify the data source, we couldn’t navigate to it on the security configuration page. The reason behind this is that it appears there is a bug with D365FO not correctly showing table field extensions in the security configuration user interface.
A current solution to this problem is to is to create the object and assign it to a privilege via Visual Studio in the AOT and then proceed with field-level security using the security configuration page as usual. To accomplish this, you would first create a new privilege and assign the menu item at the read level.
Let’s try the process in the AOT, let’s create a privilege and assign the EcoResProductdetailsExtendedGrid menu itme display at a Read level:
Then let’s add in the InventTable at an Update level:
And finally let’s try and add the AMTest table field at an Update level:
We can see that the AOT let’s us add this table field successfully.
Once we build and sync the project in the AOT, if we go into the Security Configuration window in the UI we can see it does correctly show the table field value:
Now let’s go and assign all of the other table fields on the InventTable at a Read level:
And let’s go and test the security we created. We can see in this case that all of the other fields on the form are read only and the AMTest field is set at an update level:
And we can successfully input data into this field and save this data without any issue:
Conclusion
There appears to be a bug in the user interface in the Security Configuration area that table field extensions are not being shown for tables. So if you want to assign access at a table field level for custom field extensions it must be done via code in the AOT.