Skip to main content

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

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 Priebe works directly with end users and finance professionals daily — often brought in where others have not been able to find a solution. That field work is the source of everything she writes. After more than 20 years with Microsoft Dynamics NAV and now Dynamics 365 Business Central, her focus is on why the system behaves the way it does, not just what it can do.

Her work centers on the scenarios that don't always behave as expected and aren't always documented — particularly permissions and security behavior, financial reporting, and post–go-live configuration. Much of her content addresses functionality that didn't get fully configured at go-live, capabilities organizations didn't know existed, or setup that needs to evolve as the business changes.

Cynthia is a Microsoft MVP in Business Applications — Dynamics 365 Business Central, a Microsoft Certified Trainer (MCT), and has held the MB-800 Business Central Functional Consultant certification since it first became available. Before the exam launched, she was part of the worldwide team that wrote the original exam items. She also works with Microsoft Partners and ISVs, contributing practitioner-level knowledge to how BC is built, documented, and taught.

A regular presenter at DirectionsNA, DynamicsCon, and Community Summit, she is also a co-leader of the DUG Mentorship Meetup Group, owner of the Sharing the Righter Way™ LinkedIn community, and served on the Programming Committees for both Community Summit 2024, 2025 and DynamicsCon 2026.

You can connect with Cynthia on LinkedIn or join the Sharing the Righter Way™ LinkedIn community. In addition to her contributions here ...

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.