Forum Discussion
Inherited group-based license service plan checkboxes are now editable but fail on save
Hello,
We are observing a possible UI regression in the Microsoft 365 admin center related to group-based licensing.
Environment / scenario:
- Microsoft 365 admin center
- User-level “Licenses and apps” screen
- The user receives the Microsoft 365 license through group-based licensing
- The source group is a Microsoft Entra dynamic security group
- The license and service plan settings are intended to be controlled at the group-based license assignment level
We understand that when a license is inherited from a group-based license assignment, the apps/services for that inherited license should not normally be changed directly at the individual user level. The service plan configuration should be managed at the group/license assignment level.
However, the current UI behaviour is confusing.
Observed behaviour:
1. Open a user in the Microsoft 365 admin center.
2. Go to the user’s “Licenses and apps” screen.
3. The user has a Microsoft 365 license inherited from a group-based license assignment.
4. Some app/service checkboxes appear to be enabled and editable.
5. An administrator can actually clear/uncheck those checkboxes.
6. However, when clicking OK/Save, the operation fails with an error.
In other words, the UI allows an administrator to make a change that cannot actually be committed.
The reason this looks like a regression is that the previous UI behaviour was different.
Previously, when a user’s Microsoft 365 license was inherited from a group-based license assignment, the relevant app/service checkboxes on the user-level “Licenses and apps” screen were greyed out or effectively read-only. Administrators could visually understand that those service plan settings could not be changed directly at the individual user level.
Recently, those same checkboxes appear to be active and editable. The administrator can uncheck them, but the change fails only after clicking OK/Save.
From an administrator UX perspective, this is confusing because the UI appears to allow an unsupported operation and only rejects it at save time.
Expected behaviour:
If service plan settings for an inherited group-based license cannot be changed at the individual user level, we would expect one of the following behaviours:
- The checkboxes should remain disabled/read-only from the beginning.
- The UI should clearly state that these apps/services are inherited from a group-based license assignment.
- The Save/OK button should be disabled for changes that cannot be applied.
- The UI should provide a link or guidance to manage the setting at the group-based license assignment level.
Questions:
1. Has anyone else observed this recent change in behaviour?
2. Was this UI change intentional?
3. Is this a known issue or known UX regression in the Microsoft 365 admin center?
4. Is there any scenario where these checkboxes are intentionally editable for a user who receives the license only through group-based licensing?
5. Does this behaviour differ depending on whether the source group is an assigned security group or a dynamic security group?
6. Is there any recommended administrator workflow when troubleshooting service plan settings for a user whose license is inherited from a group-based license assignment?
To clarify, this is not a question about how group-based licensing works. The concern is specifically about the UI behaviour where inherited license service plan checkboxes were previously greyed out, but now appear editable even though the change fails on save.
If this is not intentional, it would be helpful if the Microsoft 365 admin center could restore the previous read-only/greyed-out behaviour, or clearly explain in the UI why the change cannot be saved.
Thank you.
1 Reply
1. Has anyone else observed this recent change in behaviour?
Not from me2. Was this UI change intentional?
Seems no3. Is this a known issue or known UX regression in the Microsoft 365 admin center?
Seems not as knwon issue at the moment but likely and unacknowledged UX regression4. Is there any scenario where these checkboxes are intentionally editable for a user who receives the license only through group-based licensing?
No5. Does this behaviour differ depending on whether the source group is an assigned security group or a dynamic security group?
No difference for this behavior6. Is there any recommended administrator workflow when troubleshooting service plan settings for a user whose license is inherited from a group-based license assignment?
Take this:Go to:
Billing > Licenses
Select the license SKUReview:
Assigned groups
Service plan configuration
Modify:
'Apps and services' at the group level
Validate:
Check group licensing status or errors