In the past, I’ve written about the Table Permission Framework functionality within D365FO but recently I’ve had numerous examples of this causing D365FO users issues when setting up security. Because of this, I wanted to write about it again to explain how the feature works, how to troubleshoot security errors caused by the TPF, and how to remediate it.

Table Permission Framework (TPF) Overview

As a recap TPF is used to provide an extra layer of security to your high business impact data (credit card numbers, social security numbers, etc). It is an extra check that the security framework does that requires that the user has been granted explicit rights to the table field for them to be able to interact with it. So even if a user has been given Delete permission to a table through a role, duty, or privilege they still need to be explicitly granted permission (can only be View or Update) to a field with this functionality turned on for them to actually have rights to it.

The property that controls this in the AOT is a parameter on the table field called AosAuthorization, if the value is set to ‘Yes’ then the table permission framework is active.

In AX 2012, this feature was somewhat cumbersome to use as you had to turn it on for the table and then go to each individual field and turn it on or off respectively. In D365FO, you can now go directly to the table field you would like to turn this feature on for, and enable it without having to worry about the table level aspect.

So what does this look like and how to do you diagnose it? And more importantly, how can you fix it?

Scenario #1:

A D365FO user complained that certain users would get an error when trying to interact with Customer Free Text Invoices.

Access denied to field Packing duty license number (TaxLicenseNum) in table Customers (CustTable)

The user tried granting read permission to the CustTable but the error persisted.

If we check in the AOT we can see the TaxLicenseNum table field has AOS authorization turned on for the CustTable table.

Scenario #2:

A D365FO user reached out saying that they had users who were unable to Generate payments for Vendors.

Generate payments Access denied to field Bank account number (AccountNum) in table Vendor bank accounts (VendBankAccount).

The user in this case granted Delete to the VendBankAccount table trying to get this to work to no avail.

A check of the AOT again confirms that AosAuthorization is turned on for this AccountNum table field on the VendBankAccount table.

The Fix?

We need to grant explicit access to these table fields to these users either by creating new security or by using current security. To figure out what current roles (and maybe duties and privileges depending on our use case) grant explicit permissions to those fields we have a couple different options.

1. Use the View Permissions in Security Configuration for each role using in D365FO (discussed further in How to Simulation the Security Development Tool in D365FO),
2. Use reporting in the AOT and generate the extremely large View Related Objects and Licenses for All Roles report and filter that report down (an example of how to do this is shown in Security Reporting for D365FO in the AOT)
3. Use a tool like Fastpath to easily see what roles, duties, and privileges have this information.

If we look at Scenario #1 specifically, and we wanted to see all roles that are granted explicit access to the TaxLicenseNum field on the CustTable we would run a Role Access report for all roles and apply an advanced filter for that table field.

If we wanted to get detailed role, duty, privilege information we could run the Role Access Detailed report for the exact same parameters.

Using this information we could now go back and grant the necessary access to the users so they could perform their tasks.

Hopefully this post shows why the Table Permission Feature feature is important, how it is implemented in D365FO currently, and how to diagnose a TPF security issue and resolve it.

If you have any questions about this feel free to reach out!

References:

Manage Data Access by Using Table Permissions Framework

Table Permissions Framework Reference