Copilot group-based licensing scales well but still needs regular checks

On paper, Copilot group-based licensing looks like the answer for large rollouts. You stop assigning licences by hand, link them to department groups and let the system take over. In real tenants, though, I've often seen group-based assignment bring problems of its own, particularly once the environment grows and several admins start touching it. Sooner or later someone keeps asking the same questions: who has Copilot, why do they have it, and are they still using it?

Group-based licensing for Copilot works through security, mail-enabled and dynamic groups

You assign Copilot licences to groups in the Entra admin center (Entra ID → Billing → Licenses) or in the Microsoft 365 admin center (Billing → Licenses → Assign to group). Security groups and mail-enabled groups are supported, and so are dynamic groups, which matter most here. These are usually based on department or office attributes such as department or physicalDeliveryOfficeName. I come across dynamic groups like "All Marketing" (with a rule like (user.department -eq "Marketing")) in nearly every project. In theory they update on their own when users join or leave, or when HR changes an attribute. In reality it often takes a while before a user drops out of a group and loses the licence, so you still have to check regularly. Microsoft's documentation on group-based licence assignment goes through the technical limits and quirks in detail.

The Copilot Usage report shows which users have stopped using their licence

Most of the money wasted on Copilot goes to inactive users. The licences aren't cheap, so most organisations want them back from anyone who hasn't touched Copilot in a while. The Copilot Usage report (Microsoft 365 admin center → Copilot → Usage) helps here, because it shows users who haven't been active for 30 days or more. In larger tenants I use it as the trigger for a group membership review, or I go a step further and remove users from the licence group automatically once their activity drops below a set threshold.

Tip: Pair dynamic group assignments with a scheduled look at the Copilot usage report. That keeps costs under control and stops your assignment logic from drifting.

If you want to go deeper into auditing and reassigning licences, read my post on reviewing Copilot licences and reallocating them.

Mixing direct and group assignments causes the most trouble

The problem I run into most often is users who have a direct Copilot assignment and a group-based one. It tends to happen without anyone noticing. Someone gets a direct licence and is later added to a group that already grants one. Both admin centers can then show errors, and if you remove one assignment the other may stay behind, so licences end up in limbo or features are switched on inconsistently. The fix is to pick one method, direct or group, and never use both for the same users. Then clean up the old direct assignments. Microsoft Graph PowerShell makes it easy to filter for direct Copilot licences (you need the License Administrator role and PowerShell 7):

# PowerShell: List all users with a direct Copilot licence (Microsoft Graph PowerShell, License Admin role)
Get-MgUserLicenseDetail -All | Where-Object {
    $_.SkuPartNumber -eq "MICROSOFT_365_COPILOT" -and $_.IsAssignedDirectly
} | Select-Object UserDisplayName, UserPrincipalName

Run this in PowerShell 7 with the Microsoft.Graph module and License Admin permissions.

A request workflow gets licences to the people who need them

Copilot shouldn't be on by default for everyone. Many organisations now use a simple request and approval process, sometimes automated through a ticketing tool or the Power Platform. The technical side is simple. Once a request is approved, the user is added to the Copilot licence group (or removed from it). What you gain is a clear audit trail and a process that works the same way every time. You can also add usage-based removal, so anyone who goes inactive is taken out of the group. One warning: if you rely only on group-based assignment, always remove users from the group and never take the licence away directly, otherwise you're back in the duplicate assignment trap.

Most licensing errors trace back to groups, attributes or prerequisites

These are the issues I see most often in practice:

• Licence assignments that are delayed or missing (usually group or attribute sync problems)
• Users getting invalid licence errors (often a missing prerequisite, such as no mailbox)
• A licence that shows as active while Copilot features don't work (e.g. sync problem)
• Orphaned licences that remain assigned when the group logic fails

When one of these comes up, look at the assignment details in the admin center and go through the dynamic group rules. For affected users, the licence blade in the Entra admin center usually shows you the cause. The flowchart below sums up the process:

flowchart TD
    Start["User requests Copilot"] --> Review["Approval/Department check"]
    Review --> Group["Add to licence group"]
    Group --> Licence["Copilot licence assigned"]
    Licence --> Usage["Usage report review"]
    Usage -- "Inactive" --> Revoke["Remove licence"]
    Usage -- "Active" --> Keep["Retain licence"]
    Revoke --> End["Licence reclaimed"]
    Keep --> End

Figure: Group-based Copilot licence assignment with a review based on usage.

Group-based licensing still needs someone to look after it

Group-based Copilot licensing seems like a solved problem, and on the technical side it largely is. The people and process side isn't. You need a regular review, a clear rule (direct or group, never both) and someone who actually watches the usage data. Without that, you waste budget, frustrate users or lose track of who has access. The best setups I've seen treat licence assignment as an ongoing workflow rather than a one-off project. And in my experience the next audit always turns up earlier than expected.