Understanding Hierarchical Permission Sets in Business Central

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

The recent updates to Microsoft Dynamics 365 Business Central permissions introduced significant changes that improved flexibility and control. As discussed in Part 1 of this 4-part series, User Groups are deprecated and Security Groups added.  This post dives into how permission sets now support a hierarchy providing enhanced functionality while streamlining user management and security in Business Central.

From User Groups to Security Groups

User Groups previously served as a way to manage permissions collectively. However, Security Groups have taken their place, offering integration with Microsoft Entra ID and simplifying user and role management. While this is a big shift, the hierarchical structure of permission sets does compensate for much of the lost functionality of User Groups, providing a more modern and robust approach.

The New Hierarchy in Permission Sets

Permission sets now support a hierarchical model, allowing the inclusion of other referenced permission sets. This setup makes it easier to:

1. Add permissions systematically through referenced sets.
2. Exclude specific permissions as needed within the added set, offering precise control over access.

This flexibility replaces some of the functionality that User Groups previously provided, making it easier to adapt permission management to complex organizational requirements.

Types of Permission Sets

There are two types of permission sets in Business Central:

1. System Permission Sets
   • Predefined by Microsoft.
   • Not editable.
2. User-Defined Permission Sets
   • Fully editable and can be tailored to specific business needs.
   • Can be created from scratch or by copying existing permission sets using one of three methods: Clone, Flat, or Reference.

Methods for Copying Permission Sets

When creating user-defined permission sets, Business Central offers three approaches to copy existing sets:

1. Clone
   Creates an exact copy, including all referenced permission sets and base/override permissions.
2. Flat
   Extracts all permissions into rows within the base or override section of the new set. Referenced sets are not included, creating a “flattened” version.
3. Reference
   The new set only references the original set, maintaining a direct link. Updates to the source set automatically reflect in the referenced set.

Customizing Permissions in Hierarchical Sets

User-defined permission sets can include additional referenced sets or base permissions. Here’s how permissions are managed:

• Adding Permissions: To add permissions, select an object, choose “Include” to specify the addition of permissions such as Read, Insert, Modify, Delete, or Execute.
• Excluding Permissions: Choose “Exclude” to limit access to a specific action or object such as Read, Insert, Modify, Delete, or Execute.

Permissions in the base level apply only to the current set and do not cascade to referenced sets, maintaining strict boundaries between permissions.

Priority Rules in Permission Conflicts

When a user is assigned permission sets with conflicting permissions (e.g., one set grants access and another excludes it), the exclusion takes precedence. However, Microsoft documentation on this behavior has varied and is not always clear, so I advise thorough testing to ensure the correct permissions are applied.

Fortunately, Business Central includes tools to test permissions before applying them in production, reducing the risk of misconfigurations.

Indirect Permissions

Indirect permissions allow users to interact with objects indirectly via another object. For example, a user with permission to execute the Sales-Post function can indirectly insert records into posting tables, even without explicit permission to modify those tables. This ensures processes remain seamless while maintaining security boundaries.

When Permission Sets Can’t Replace Groups: A Use Case

Consider a scenario where a user needs access to G/L accounts for transactions but must have restricted access to G/L Entries. This cannot be achieved with a single referenced permission set. Here’s how to solve it:

1. Create two separate permission sets:
   • One for selecting G/L accounts.
   • Another with restricted access to G/L Entries.
2. Assign these permission sets directly to a Security Group or directly to the user (do not reference them within other permission sets).
3. Use Effective Permissions to confirm G/L Entries are excluded at the base level in any other assigned permission sets as needed. To do this, you may need to set exclusions directly in the base permissions of other assigned permission sets.

Best Practices for Administrators

1. Plan Carefully: Structure permission sets with a mix of system and user-defined sets to ensure scalability.
2. Test Permissions: Always test permissions in a sandbox environment to avoid surprises in production.
3. Document Changes: Maintain clear documentation of how permissions are granted or excluded, especially in complex setups.

With these changes, Business Central’s permission structure has become more flexible and secure. To dive deeper into assigning permissions, check out the official documentation: Learn Microsoft – Assign permissions to users and groups. By leveraging these updates, administrators can achieve more precise control over user access while simplifying permission management. And as always, you may find there is more than one right way to set up permissions, but there will be one Righter Way for you.