Post to a GL account but not see general ledger entries or account balances

Problem:

I need a user to be able to post selecting a GL account in a journal or document, but not see account balances in the chart of accounts, general ledger entries, or any reports on the same data.

Solution*:

You can limit a user to only seeing and using a GL account and not have access to its related general ledger entries or report on account balances. In other words, they can select the GL Account on a journal line or in a document.

Is there a difference in what needs to be done if you are using User Groups and in later versions when user groups are no longer available?

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 the setup to be able to select GL accounts that is no different when using or not using User Groups.

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

Earlier than version 23.0 or not yet upgraded to replace User Groups with Security Groups and Permission Sets, I recommend assigning the above permission sets to the user without using a user group (since these will be going away anyway). If the user can see GL entries, use Effective Permissions to find and resolve any conflicts.

If you are reading this because your GL Post only permissions are broken after the user group upgrade with version 23.0 then 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 composable permission set referencing the permission sets that were included in each user group. The new permission set is assigned to all members of each user group. The permission set created with the upgrade for GLPOSTONLY user group will not work properly. You must assign the permission sets directly to the user, not as the newly created permission set with the original permission sets referenced. Delete the permission set created with the user group upgrade.

However, during the user group upgrade if you selected the option to “Assign to user”, the permission sets in all user groups are assigned directly to the users who were assigned to the group, and removes their user group assignments. Users that selected this option probably aren’t reading this blog post. Their permissions for GL Post Only are probably working correctly. Users that selected the “Assign to user” option need take no further action.

More information from Control Access Using Security Groups – Business Central | Microsoft Learn

“Security groups are new to Business Central in 2023 release wave 1. They make it easier for administrators to manage user permissions by allowing them to group users by department, job function, and so on. Administrators assign the permissions to the group that its members need to do their jobs.

Security groups are similar to the user groups that are currently available. However, user groups are only relevant for Business Central. Security groups are based on groups in Microsoft 365 admin center or Azure portal. That benefits administrators because they can use their security groups with other Dynamics 365 apps. For example, if salespeople use Business Central and SharePoint, administrators don’t have to recreate the group and its members.

Security groups will replace some of the functionality of user groups in a future release. Other features of user groups and their benefit to managing permissions for groups of users will be replaced by composable permission sets and the referenced permission sets they include. You can continue using user groups to manage permissions until then. To start using security groups and composable permission sets now, your administrator can turn on Feature: Convert user group permissions on the Feature Management page. To learn more about security groups, go to Control Access to Business Central Using Security Groups.”

Summary

If using Security Groups,

1. Create an AAD Security Group “GLPOSTONLY”
2. Create a BC Security Group with code “GLPOSTONLY” “Post to G/L Only”. Select the AAD Security Group of the same name to link BC to AAD.
3. Assign permission sets to the BC Security Group:
   1. GL ENTRY POST 1 “Allow to post not view GL 1 of 2”
   1. GL ENTRY POST 2 “Allow to post not view GL 2 of 2”
4. Permissions will be granted to the user based on AAD Security Group(s) assigned.

If not using Security Groups,

1. Assign permission sets directly to the user.
   1. GL ENTRY POST 1 “Allow to post not view GL 1 of 2”
   1. GL ENTRY POST 2 “Allow to post not view GL 2 of 2”
2. Do NOT include these permission sets in another permission set as a reference.

I hope this new information speeds you along on your journey to using BC The Righter Way^TM

*Revised 09/14/23