Difference between User Groups and Security Groups
User Groups act as containers to assign and manage multiple permission sets efficiently. On the other hand users can also be assigned to these groups. When this is fully setup, you only have to add new users to this group and they will receive the permission sets linked to this group on their user card. Changes to the permissions of the user group will also affect all the existing users linked to this group.
Security Groups are not Business Central specific but can be used to control access across the entire Microsoft 365 environment. Nested permissions allow administrators to build hierarchies and layer permissions. This security setup operates at the network level, providing a higher-level control compared to application-specific configurations. This setup requires only an understanding of the user's role (e.g., HR function) at the infrastructure level, and everything underneath, for Business Central the permission sets, will be linked to that.
|
Security setup with user groups |
Security setup with security groups |
|
Entra ID / User ID |
Security Group: PURCHASE |
|
User Group: PURCHASE |
CRM; BC; SharePoint |
|
Permission: Create PO |
Nested Permission: PURCHASE |
|
Permission: Post PO |
Permission: Create PO |
|
|
Permission: Post PO |
Permissions and permission sets
Not only did the User Groups deprecate but the permission sets have been updated with a new functionality. It’s important to understand this new functionality as this will be the new way to combine and group permission sets in Business Central moving forward.
Permissions define what actions users can perform and which objects they can access. Each permission specifies if a user can READ, INSERT, MODIFY, DELETE or EXECUTE within certain areas of the system. The updated functionality introduces "nested" permission sets, enabling one set to inherit permissions from others. For example, you might have a PURCHASE set that includes the “Create PO” and “Post PO”. Instead of assigning these to User Groups or individually, you assign the “PURCHASE” permission set which automatically grants the user all permissions from the nested sets. The relationship between these included permission sets and the container itself is dynamic, meaning that if you update the “Create PO” permission set, it will also affect the “PURCHASE” set.
How to transition
If you now rely on User Groups, you may wonder how to transition to the new features. This conversion will create a new (nested) permissions set for the permissions in the user group. The new permission set is assigned to all members of that user group. While the migration wizard provides a convenient transition, now is the perfect opportunity to reevaluate and update your permission management. This ensures your access controls align with your business needs, especially in times of change. The default way of evaluating permission sets is to open the card of one set, and click on “effective permissions” at the top of the screen. The downside of this is that you’re now only looking at objects in a set, which makes it difficult to determine which objects should be there and which shouldn’t. You’re also only looking at one permission set, and you’re likely to have a lot more. And to make it even more complex, with this review you also need to consider that fact that users can have multiple different permission sets linked that can create new conflicts that override the objects in only one set.
Luckily for this, we have created the monitoring module in our Authorization Box. With this module you can review your security setup with a risked-based approach and can get analysis results on users, permission sets and organization roles. You can also write a formal review on each of these results which the system will remember and only ask you to review again after the permissions change. In this module you can set up critical permissions that monitor access to all types of objects. Therefore the reviewer only has to look at the critical permission “Who can change the Vendor bank account?” instead of going through all the permission sets to find out who had modify rights on tabledata 288 (Vendor bank account table). These critical permissions can also be combined to create critical conflicts. For example, “Who can change the Vendor bank account?” can be a conflict with “Who can create payment proposals?”. On a critical permissions level, it’s likely that some users in the organization have these rights. But if a user has the critical conflict, so access to both critical permissions, you might have some risk-mitigation steps to take.
Do you still want to have some kind of user group functionality? Then we have the ability to create an organization chart with organization roles in the Authorization Box. These organization roles can be linked to permission sets and users and with this you can leverage a standardized security setup. Another plus-side of this setup is that you can set up approval flows for assigning organization roles, and all activities are logged so that everything can be traced back to a user.
