Dynamics 365 Business Central access control challenge: Setting up GL Post Only permission sets

This document was written by Cynthia Priebe. I was so impressed with how simply she defined and solved this issue that I got her permission to share on my blog site.

by Cynthia Priebe, Senior Trainer and Consultant, New View Strategies

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:

  1. Object Type – Table Data
  2. Object ID – 17 (G/L Entry)
  3. Read Permission – Yes
  4. 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:

  1. Object Type – Table Data
  2. Object ID – 17 (G/L Entry)
  3. Read Permission – Indirect
  4. 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.

Thank you, Cynthia Priebe!

Leave a Reply

Your email address will not be published. Required fields are marked *