I have written in the past about using field level security to help secure sensitive information within your D365FO environment, but what if the field you want to secure doesn’t correlate directly to a SQL table field and instead is populated by a data method? Let’s see how you can still secure this!
Scenario
Let’s say I want to secure the Bank Account Number field on the Vendors form, if I try to use my normal field level security techniques of securing this field I quickly find that this field is not available to secure.
If we use the Right Click -> Form Information method we see why this is:
We can see the type is a Form String Control and that there is no ‘data field’ listed. Instead a Control is listed (Payment_M_bankAccountNum).
If we go into the AOT and search for that control on the VendTable form object we can see this actually ties to a Data Method called ‘bankAccountNum’ on the VendTable table object.
Navigating to the code behind the VendTable table object, we can find the bankAccountNum() method and see that it is using a combination of the VendBankAccount and BankAccount tables. It performs some business logic but in the end it returns the value from the AccountNum table field on the VendBankAccount table object.
So let’s go deny access to that table field by creating a role that grants access to the VendTableListPage menu item display and then denies access o the VendBankAccount -> AccountNum table field.
Now when I assign this access to a user I can see that I still can see the vendor but the Bank Account Number field is not shown.
Conclusion
Hopefully this blog post shows the process of securing a form field that isn’t directly populated form a table field but instead a data method.
Also want to give thanks to Dogan Adiyaman for reaching out and sparking this blog post, as always feel free to reach out with your security questions as they can become blog posts!