Dynamics 365 Business Central access control challenge: Setting up GL Post Only permission sets
FREE Membership Required to View Full Content:
Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more. You can also receive periodic email newsletters with the latest relevant articles and content updates.
Learn more about us here
So, here’s the situation. Users have been set up with permissions in Microsoft Dynamics 365 Business Central (BC) that allow them to post using a GL account in a journal or document, but not see account balances in the chart of accounts, general ledger entries, or any reports. This has been working perfectly until…. user groups were updated to permission sets. Now, users can not only select GL accounts on transactions, but they have access to balances and GL entries from chart of accounts and in reports.
What happened when I updated my user groups to permission sets? In the event you are new to this capability, here is a bit of background.
Limiting GL Entry view is possible in all versions of BC
You can limit a user to only seeing and using GL accounts and not have access to its related general ledger entries and reporting. This includes account balances from the chart of accounts and financial reports. In other words, they can select the GL Account on a journal line or in a document, but not see posted entries.
Is there a difference in what needs to be done before and with Version 22.0 and after?
If you don’t already know this, soon User Groups will no longer be available. They are going away and being replaced with functionality in Security Groups and by referenced permission sets. Let’s start with what is not any different either before or after converting user groups to permission sets. There are two permission sets you need to create and assign to users so they can post using a GL account in a journal or document, but not see account balances in the chart of accounts, general ledger entries, or any reports.
Create 2 Permission Sets
Permission Set GL ENTRY POST 1 “Allow to post not view GL 1 of 2”. Permission to include:
- Object Type – Table Data
- Object ID - 17 (G/L Entry)
- Read Permission - Yes
- Security Filter G/L Entry No. = 0
Permission Set GL ENTRY POST 2 “Allow to post not view GL 2 of 2”. Permission to include:
- Object Type – Table Data
- Object ID - 17 (G/L Entry)
- Read Permission - Indirect
- Insert Permission – Indirect
Individually assign Permission Sets
In the past, I would have recommended you “wrap” these permission sets in a User Group and assign the User Group to the user. But now that user groups are going away, this recommendation could cause problems when you upgrade away from user groups. Without user groups, you will now need to assign these permission sets directly to users. In testing, if the user can see GL entries, use Effective Permissions to find and resolve any conflicts with other assigned permission sets.
If your “GL Post only” permissions are broken after the user group upgrade, this section is for you!
During the user group upgrade, if you selected the option to “Convert to a permission set”, BC will create a new permission set referencing the permission sets that were included in each user group. Then the new permission set is assigned to all members of each of the replaced user groups.
FREE Membership Required to View Full Content:
Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more. You can also receive periodic email newsletters with the latest relevant articles and content updates.
Learn more about us here
Few caveats here
Cynthia,
Fantastic article, very concisely described and easy to follow. I came across it after going through the process of restricting GL visibility in an environment, but continued running into posting issues. Basically needed exactly as you're described, need users to be able to post day to day transactions but not be able to see sensitive company financials (aka Chart of Accounts, or GL Entries at-least).
Anyway, there is one scenario that I've come across to date where the above does not work. Appears to be a code issue where Microsoft is doing something different with the code in this scenario than others, but it's to do with posting Assembly Orders. The described Permission Set setups described in this article, and as i have implemented, still block posting Assembly Orders. There is a work around which is to turn OFF (or set to Never) "Automatic Cost Posting" on the Inventory Setup, only then does the line of code that causes the Permission Error get skipped.
So, all in all a great article, but just needed that one caveat added. Hopefully Microsoft fix this code in future.