RSMUS.com“…But they shouldn’t be able to see General Ledger details.”
If you’ve implemented Dynamics NAV/D365 Business Central you’ve heard that question as many times as you’ve implemented the product. The common response is to play with removing table access or add code that hides specific tables. Maybe you even played with an ISV solution or filtering your security roles just to hide those pesky accounts from visibility. This is doable just using base system security functionality and some filters once you understand the process.
Process
First, let’s talk process. I need to have a user post a sales transaction to a revenue account. Base permission sets immediately give full read access to the G/L Entries table allowing direct visibility to our trial balance. If I remove that and say set their read to indirect I then immediately receive an error so revert and sign it off as oh well. Behind the scenes, the system is utilizing that table during the posting process and so needs the ability to read that detail.
To resolve this issue I need to add 2 permission sets so that I can control read and insert/update separately.
Permission sets
For the first permission set, I can set access to the G/L Entry table data (17) with Read set to Yes. I can then set a filter on that table data where Entry No. = 0. During the posting process, the entry is added temporarily with a 0 until it fully posts. In other words, the system can now see the detail in that table as it posts but not after.
For the second permission set, I also add access for table data G/L Entry (17) but in this set, I set just Insert and Update to Indirect which will allow the posting process to fully interact with the table. Now the standard posting process will be able to create and update those records.
Finally, I don’t want to add those separately so we throw them into a User Group (existing or new) so that we can apply all detail at the same time. Make sure you remember that the system is optimistic so you also need to validate none of your other permission sets override this! (Effective Permissions will save you here)
Now when a user posts the transaction they are able to select their GL code and post the transaction. If they then go to the Chart of Accounts they can’t see our values because they don’t have access to the actual ledger entries. They can even go to the posted document and run a …Find Entries which won’t show any GL impact since we took away their access to that table (Yes, it still posted properly).
Should Indirect Read accomplish this? Maybe, but it doesn’t, so building just a couple permission sets can give us that control and segregation of duties we need and remove that need for an ISV or custom code just to hide some small data points.
