What Microsoft removed, and when
Microsoft deprecated user groups in 2023 release wave 1 (version 22) and introduced security groups in the same wave. The note on Microsoft's own help page for the legacy feature is short: "Security groups replace user groups starting in 2023 release wave 1 (version 22). User groups aren't available after 2024 release wave 1 (version 24)."
The deprecation list is filed under 2024 release wave 2, where the entry reads: "User groups are replaced by security groups." The version numbering in Microsoft's documentation is not entirely consistent across those pages, which is worth knowing if you're trying to match a statement to a specific environment. The practical position is the same either way. On Business Central online, user groups are gone. On-premises versions 22, 23 and 24 still have them, along with the assisted setup guide that converts them.
Twenty-four objects went with the feature, including the User Group and User Group Member tables, the Permission Set by User Group page, the Copy User Group report and the Export/Import User Groups XMLport. If anyone on your team scripted a setup or an onboarding routine against those, that script stopped working.
Two replacements for one feature
User groups did two jobs, and Microsoft split those jobs across two features. That is the confusing part of this change.
Security groups: the container moved to Entra ID
A user group was a Business Central object. A security group is a group in Microsoft Entra ID for online deployments, or in Windows Active Directory for on-premises with Windows authentication. Business Central holds a link to it plus the permission sets behind that link.
Microsoft's reasoning is reuse across applications: "if salespeople use Business Central and SharePoint, administrators don't have to recreate the group and its members." That's a real gain, and it comes with a shift in ownership. Membership is no longer something a Business Central admin changes on a page in Business Central. It's something the Microsoft 365 admin changes in Entra ID.
For on-premises deployments using Microsoft Entra authentication, security group support requires Business Central version 25.11, 26.5, 27.4 or later.
Nested permission sets: the grouping that stayed inside
The second job, bundling several permission sets into one, moved into the permission sets themselves. On the Permission Set page you add other permission sets on the Permission Sets pane, and the Result pane lists everything that comes in through them. Change an included set and every set that includes it changes with it.
One rule inside that mechanism is easy to miss: "If a permission is in both an included and excluded permission set, the permission is excluded." Business Central calculates the full list of included permissions, then the full list of excluded ones, and subtracts the second from the first. Exclusion wins, no matter how many sets granted the permission. If you're building layered sets, our post on the SUPER permission set covers where that logic matters most.
How to migrate
Step 1: run the User Group Migration guide, if you still can
This step applies to on-premises versions 22, 23 and 24. On the Feature Management page, find Feature: Convert user group permissions and set Enabled For to All Users. That starts the User Group Migration assisted setup guide.
The guide offers two options. Assign to user assigns the permissions in the user group directly to the users who were in it and removes the group assignment. Convert to a permission set creates one new permission set per user group and assigns that set to every member of the group.
If your environment is online, or on-premises past version 24, this step is behind you. What follows is the part that still needs doing.
Step 2: create the group in Entra ID
Create the security group in the Microsoft Entra admin center or the Microsoft 365 admin center and add your users to it. For on-premises with Windows authentication, create a Windows Active Directory group instead and leave EnableEntraGroupsOnPrem at its default value of false in CustomSettings.config.
Step 3: link the group in Business Central
Search for Security Groups, choose New, and select the group in the Microsoft Entra security group name field. On-premises with Windows authentication, use the Windows group name field.
Members only appear in Business Central if they exist there as users: "The users show in the Members card on the FactBox pane or the Security Group Members page only if they're added as users in Business Central." If the Members card stays empty, first check whether the users were created in Business Central.
Step 4: assign permission sets and set the company
On the Security Groups page, select the group and choose the Permissions action. Assign sets one by one in the Permission Set field, or use Add multiple.
Then look at the Company column. Microsoft states it plainly: "If you don't specify the company when assigning a permission set, the permission set then applies to all companies." In a single-company environment that's harmless. In a group with several legal entities, a blank Company field gives access in every one of them.
If a set should apply to more than one company but not all of them, add it once per company.
Step 5: verify with Effective Permissions
Open the user card and choose Effective Permissions. You need the SECURITY or SUPER permission set to view another user's effective permissions. The By Permission Set part shows where each permission comes from, including whether it arrived through a security group.
Read the brackets. Permissions coming from the subscription license appear with source Entitlement, and "the permission values of the entitlement overrule values in other permission sets if they have a higher ranking. A value in a nonentitlement permission set that has a higher ranking than the related value in the entitlement is surrounded by brackets." A bracketed value is assigned and not effective, because the license caps it. Our post on licenses versus permissions goes into where that line sits.
User group, security group, permission set: what does what
| User group (removed) | Security group | Nested set | |
|---|---|---|---|
| Members live in | Business Central | Entra ID or AD | No members |
| Used by other apps | No | Yes | No |
| Bundles permission sets | Yes | Yes | Yes |
| Company scope | Per member | Per assignment | Per assignment |
| Membership managed by | BC admin | Microsoft 365 admin | Not applicable |
| On-premises | Up to v24 | AD; Entra from 25.11 | Yes |
Five things the migration does not carry over
The security groups themselves. The guide converts user groups into permission sets or direct assignments. It does not create security groups. Creating the Entra group, linking it in Business Central and assigning permission sets per company is manual work, and every assignment without a company applies to all companies.
Your license configurations. These assign permission sets based on license type and they keep running after the migration, independently of any security group. Microsoft's advice is direct: to use security groups exclusively, remove the license configurations by opening the License Configuration page, choosing a license and deleting the permission sets assigned to it. Skip this and you have two systems handing out permissions with nobody reconciling them.
The default profile per group. User groups could set a default role center for their members. That's gone: "The default profile functionality can no longer be dynamically defined for groups of users. Instead, use the Profiles (Roles) page to specify a default profile for your company." One default per company instead of one per group. If your purchasers and your warehouse staff used to land on different role centers automatically, they don't anymore.
A review of what people had. The guide is faithful by design. It reproduces the existing situation as permission sets, including whatever accumulated over years of job changes, temporary access and departures. Nobody ever approved that state, and converting it doesn't approve it either. If a purchaser could both create a vendor and release a payment before the migration, they still can after it. Our post on segregation of duties in Business Central covers how to work out which combinations matter.
Extensions and scripts that touched user group tables. All twenty-four objects are deprecated with a [220_UserGroups] tag on the obsolete reason, which makes them easy to find in code. An extension that inserted into User Group Member needs rewriting against the Access Control table or the Security Group codeunit. An onboarding routine that ran Copy User Group needs rewriting too.
Checking what your users can actually do now
Effective Permissions answers the question for one user at a time. That's the right tool for a support call. For a post-migration review the question is different: who can now do these two things together?
That's the gap Authorization Box is built for. You set up a critical permission such as "Who can change the vendor bank account?", so the reviewer looks at that question instead of tracing modify rights on table 288 (Vendor Bank Account) through every permission set. Combine two critical permissions and you have a critical conflict, for example "Who can change the vendor bank account?" together with "Who can create payment proposals?". The migration guide doesn't look for combinations like that.
Since the update of December 2025, security groups are analyzed for risks just like users. When you review a user's analysis result, you see which permissions are assigned directly, which come in through membership of a security group, and which come from regular permission sets. After a migration that turned groups into sets and sets into group assignments, that is the distinction a reviewer needs.
The Continuous Monitoring module keeps that check running afterwards. Subscribers get a notification in their dashboard or by email when the analysis result for a critical permission changes.
