Hide Confidential Records with Security in Business Central

Blog 3 of 4 in “What’s the deal with Permissions in BC?”

In this post, we’ll explore how to manage hierarchical permissions in Microsoft Dynamics 365 Business Central (BC) to meet specific requirements.

The Challenge: Limiting Access to Confidential Vendors

The accounting department requested restrictions on accessing specific vendor records, such as subcontractors, employee reimbursements, benefits and legal services, whose payments should remain confidential. The controller or higher-level staff manages these records. This means limiting access to:

1. Vendor cards
2. Vendor ledger entries
3. Unposted, posted and archived documents (and their lines)

The solution? Security Filters in Permission Sets.

Identifying Confidential Vendors

We identified confidential vendors using the General Business Posting Group (GBPG) field. This field exists on vendor cards and propagates to headers and lines in related records. Here’s how we set it up:

1. We added a new GBPG value, “CONFIDENTIAL,” alongside the existing “PRIMARY” value.
2. Using the “Edit in Excel” feature from the vendor list, we updated the GBPG field for confidential vendors.

Testing the GBPG Filter

Initially, filtering the vendor list by GBPG (e.g., “PRIMARY”) successfully excluded confidential vendors. However, challenges arose with existing documents:

1. Documents created before the Vendor card GBPG update still retain the original GBPG (“PRIMARY”).
2. GBPG values on existing documents can’t be modified—even using “Edit in Excel.”
3. Consider a Per Tenant Extension (PTE) adding “Vendor GBPB” to the tables showing the current value from the Vendor card. Use this value in the Security filter.
4. Unposted documents will present the same limitation, however no unposted documents for confidential vendors exist in this company.

Vendor Ledger Entries – a different story

Vendor Ledger Entries (VLE) don’t have GBPG but do have Vendor Posting Group (VPG). We added a “CONFIDENTIAL” VPG alongside the existing “PRIMARY” value and assigned it to confidential vendors.

1. Documents created after this change will have the confidential VPG and vendor ledger entries posted through these documents will have the same.
2. Documents created before the Vendor card VPG update still keep the original VPG (“PRIMARY”).
3. VPG values on existing ledger entries can’t be changed.
4. Consider a Per Tenant Extension (PTE) adding “Vendor VPG” to vendor ledger entries showing the current value from the Vendor card. Use this value in the Security filter.

Vendor Posting Group vs. General Business Posting Group

As much as I tried, I could not use one vs. the other to meet all filter requirements. In the end, we created both a VPG of “CONFIDENTIAL” and a GBPG of “CONFIDENTIAL” and assigned both to the vendors and to a “Confidential” Vendor Template.

The General Business Posting Group filter applies to:

1. Vendor
2. Purchase Header
3. Purchase Line
4. Purchase Invoice Header
5. Purchase Invoice Line
6. Purch. Cr. Memo Hdr.
7. Purch. Cr. Memo Line

The Vendor Posting Group filter only applies to Vendor Ledger Entries. This is the only related table that does not have the GBPG.

Testing Hierarchical Permissions

Setting up the permissions hierarchy involved a systematic approach.

Foundation Permission Set – First Attempt

1. Create a permission set that includes broad access to all the purchase-related table data by referencing BC provided permission sets including accounts payable, accounts receivable, basic and login permissions
2. Add “Exclude” permissions for sensitive tables (e.g.. Bank Accounts, Vendor Bank Accounts, Financial Reports, and G/L Entries)
3. Add “Exclude” permissions to vendor and purchase-related tables using security filters for GBPG and VPG, excluding “CONFIDENTIAL” values.
4. Assign to TEST user.

I also assigned the permission sets to provide access to G/L Accounts without providing access to G/L Entries to the TEST user. For more on G/L Account access read Post to a GL account but not see general ledger entries or account balances – Sharing The Righter Way – Cynthiapriebe.com.

Bank Accounts, Vendor Bank Accounts, G/L Entries and G/L Accounts worked perfectly. All of the table data was excluded. However, all the table data was also excluded from the vendor list and other purchase-related list pages. A security filter applied to exclude records doesn’t work.

Foundation and Limiting Permission Sets

Next we used what I thought was the same approach I used to solve the G/L Entries requirement.

1. Create a new limiting permission set that includes vendor and purchase-related table data
   • Add “Include” permissions with security filter for GBPG and VPG, including “PRIMARY” (non-confidential) values
2. From the foundation permission set, remove “Exclude” permissions for the vendor and purchase-related tables
3. Assign both sets to TEST user.

I worked through several other iterations and modifications to the foundation and limiting permissions sets, but none of them worked. Time to call on the calvary!

Community to the rescue!

When I couldn’t find the answer in Learn, BC Community forums and other saved resources, I posted something on one of the BC community sites and hoped for an answer.

Enter David Kolenko David Kolenko | LinkedIn! Not only did David make recommendations, but when I tested those recommendations and they didn’t solve the problem, he stuck with me until we found one that worked. We both learned something new that day.

Implementing Hierarchical Permissions

Foundation Permission Set

1. Create a permission set that includes broad access to all the purchase-related table data by referencing BC provided permission sets including accounts payable, accounts receivable, basic and login permissions
2. Add “Exclude” permissions for sensitive tables (e.g.. Bank Accounts, Vendor Bank Accounts, Financial Reports, and G/L Entries)
3. Add “Exclude” permissions for vendors and purchase-related tables. Do NOT use security filters

Limiting Permission Set

1. Create a permission set that references the foundation permission set
2. Add “Include” permissions with security filters for non-confidential (PRIMARY) data.

User Assignment

1. Assign the limiting permission set to TEST user. (Alternatively, assign to TEST security group assigned to TEST user.)
2. If also limiting access to GL entries, assign these other permission sets.

Effective Permissions

Why one permission set “wins” over the other *

From Using Security Filters Learn.Microsoft documentation: “When multiple permission sets that refer to the same table data are assigned to a user, they are combined so that the least restrictive filter is used. You should not repeat a table in multiple permission sets if you plan to combine those permissions sets for one user.”

https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/security/security-filters

This should also be in Define Granular Permissions Learn.Microsoft documentation since it is not only relevant when using security filters, though it would be the most common reason for its application. I understand the inclusive warning, but in the cases to solve above this is the only option.

From Define Granular Permissions and now understood to only apply within a specific permission set: “If a permission is in a permission set that is included and is also in a permission set that is excluded, the permission will be excluded.”

https://learn.microsoft.com/en-us/dynamics365/business-central/ui-define-granular-permissions

Key Takeaways

1. Make certain to read all documentation on a topic, even those linked within said documentation that you may think not necessary to read or it does not apply. *
2. Step back. When overwhelmed, take a break.
3. Community matters. Reach out for help! The Business Central community is a valuable resource. Special thanks to David Kolenko for his guidance.
4. Complexity is a permission inevitability. Patience and testing are critical.
5. It is still possible to get at least one version of record level security with the new hierarchical permission sets and security filters. May not be the right answer for everyone, but it is a place to start.

Thank you for allowing me to share with you one of the The Righter Ways^TM for working with Business Central.

* Revised 01/03/2025 by Author