Skip to main content

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

by Cynthia Priebe - Microsoft MVP
Consultant and Managing Partner, MGC Group LLC

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

bc-permission-sets-1.png

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

bc-permission-sets-2.png

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

About Cynthia Priebe - Microsoft MVP

Cynthia is a Microsoft MVP, consultant and owner of MGC Group, LLC where she focuses on Sharing the Righter WayTM of working with and improving process efficiency in Microsoft Dynamics 365 Business Central. 

Cynthia is recognized for her ability to look at operational and reporting challenges with a fresh take and propose solutions using core features and functionality. Focused for close to 20 years on Dynamics NAV and now D365 Business Central, she adores helping clients and partners solve problems, enhance productivity, and find the best of the many ways to work in Business Central. 

She is a regular presenter at industry conferences including DirectionsNA, DynamicsCon and Community Summit. On the original team to write the MB-800 Micrsoft Dynamics 365 Business Central Functional Consultant certification exam, a member of the DUG Mentorship Meetup Group, on the Programming Committee for Community Summit 2024, a Microsoft Certified Trainer, and a certified Microsoft Dynamics 365 Business Central Functional Consultant, Cynthia enjoys giving back to the community in thanks for all it has given to her.

You can reach Cynthia through LinkedIn

In addition to contributing her ...

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

Alan
Submitted by Alan Nash on Thu, 02/01/2024 - 20:18 Permalink

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.