The latest on BC Permissions for posting without permission to view G/L Entries

If you have been following me for any length of time, you will have seen previous posts about permissions either here, in LinkedIn or as articles in MS DynamicsWorld.

It has been a real challenge keeping up with the changes in permissions, but I can say that after working them recently with a couple of customers, I have learned quite a bit about the new permission hierarchy. Most of it through trial and error. One lesson learned is on how to set up permission sets so that users can select and post using a GL Account without seeing any of the GL entries.

I posted previously (for NAV and earlier versions of BC (prior to user group deprecation)) to create a user group containing 2 permission sets and assign it to the user. This changed with the inclusion of composable permission sets. We could no longer combine the sets in a group. We needed to assign them directly to the user. And everything I am talkin about in the past and here today is not using Security Groups. I haven’t really gotten into these too deeply yet. I am here today to share with you yet another nuance in permission setup.

First of all, let me be clear, the permission set definitions for G/L Entry TableData are the same. How I am assigning them is different and has become a bit more complicated. I think I can explain it in a way that will make it easier for you to understand. Follow along…

Determining what permission sets are providing G/L Entry Read

1. Go to the User Card of the user you want to limit G/L Entry Read abilities.
2. Run Effective Permissions and find TableData (17) G/L Entry. Select this row.
3. From the bottom of this page, view access provided By Permission Sets.

Modify Permission Set for one user

1. From the user card, select the User Permission Set providing the undesirable access to G/L Entries, select Permissions from the line menu.
2. Add an “Include” line for Table Data G/L Entry, Read Permission with a Security Filter of G/L Entry: Entry No.=0
3. Repeat steps 1 & 2 for every permission set providing G/L Entry permissions.

View Effective Permissions to confirm changes

1. Return to the user card to view Effective Permissions again. 
2. Select Table Data G/L Entry to view indirect and filtered read permissions.
3. You might see something like this for GL Entries. At this point, you won’t see GL Entries in BC, but you will also not be able to post to the General Ledger. You will get this error “A security filter has been applied to table G/L Entry. You cannot access records that are outside of this filter”

Create Permission Set to post G/L Entries

I found the easiest way to address the error and allow posting is to add a permission set with only one line. I name the permission set GL ENTRY INDIRECT. This permission set should be added directly to any user you will be defining with the limited GL Entry read permissions that needs to post transactions. I have found that referencing this permission set within another permission set does not work. The permission set should be defined like this and attached directly to the user:

Assign “Posting” Permission Set to user

Assign this permission set to any user who you have limited G/L Entry to Indirect Read with the security filter.

With the inclusions to GL Entry with the security filter and the “posting” permission set, the user will be able to post transactions however not see GL Entries.

Effective permissions should look something like this.

If you found this blog post helpful, please comment. I would love to hear from you.