Small and medium business | Business Central, N...

Restricting Access bei excluding Table Data or by restricting Page and Permission "Run Table"

Like (0) Share

Report

Posted on 31 Jan 2025 15:21:00 by TR-12121238-0

Hi all,

I am testing and trying to exclude access to Chart of Accounts (G/L Account (15).

1. One idea would be to create a permission set called "Exlude these objects" and add the Table 15 there (and maybe other objects that should be restricted).

After that this permission set could be excluded in a another permission set calle "Set for basic users" and this permission set could be granted to the Users:

Doing so, every table, etc. which should be restricet, could be added to the permission set "Exlude these objects" and immediately the object would be restricted.

Thats basically working but I think tricky if you need to book something into Table 15 and you need indirect rights, etc. (I need to test this a bit better).

2. The easier way could be to just exlude the Page 16 (Chart of accounts) and as well restrict System object 1350 Run table. Doing so a direct query using this syntax https://businesscentral.dynamics.com/TenantID/Environment?table=15 could be avoided. But I am not sure if this is enough and the table data itself need to be excluded as well?

What are your thoughts on this?

Thanks

Thomas

Categories:

Dynamics 365 Business Central

All responses (2)

Answers (0)

Suggested answer

Khushbu Rajvi. 8,786 Super User 2025 Season 1 on 01 Feb 2025 at 05:37:03

Like (1)

Report

Restricting Access bei excluding Table Data or by restricting Page and Permission "Run Table"

Hope this helps: https://community.dynamics.com/forums/thread/details/?threadid=ada5cbd5-12f8-ee11-a1fd-6045bdd51112
Suggested answer

CP-31051535-0 10 on 31 Jan 2025 at 20:28:57

Like (1)

Report

Restricting Access bei excluding Table Data or by restricting Page and Permission "Run Table"

This is the approach that I have been using successfully to limit permissions to GL Entries and the editing of COA. I need the user to be able to post and use GL Account in journals and transactions, but not have access to any financial data by way of GL Entries. Even to the extent of not through Find Entries.

1. Make certain that all other permission sets assigned completely exclude permissions to Table Data 17 - G/L Entry.

2. Create a permission set to Include Table Data 17 with a Security Filter of "G/L Entry: Entry No. = 0" and Read Permission Yes.

3. Create a second permission set to Include Table Data 17 with only Indirect Permission assigned to Read and Insert.

4. Assign both sets to the user or security group. Since these must both be at the highest level in the hierarchy to work correctly, they cannot be referenced within another permission set. They must be assigned directly. Confirm correct results by using Effective Permissions from the user card.

For the GL Account and other setups where I need to limit insert, modify and delete permissions, I create a permission set that in essence is the Foundation of all other permission sets. This set references many MS provided standard permission sets. In the direct permission of this same set, I exclude table data, some pages, and some codeunits. I ALWAYS try to solve using table data first, but found this is not always possible. I resort to page only when I have exhausted all other options. I also confirm the page I am excluding is the only means to accessing the data and that I don't need to exclude another page. A Table Data first approach is the best approach in my opinion because it removes the need to find all the ways a user has access.

I then reference the above "Foundation" Permission set in a permission set I will ultimately assign to users that gives them back the level of permission needed. As seen below, this can include filters.

I hope you find this helpful and maybe The Righter Way for your permissions also.

Cynthia