How to Configure Microsoft Teams Policies by User Group

Assigning Teams policies to individual users is fine when your organisation has thirty people. At three hundred, it's a constant source of support tickets. At three thousand, it's simply not sustainable. Group policy assignment was Microsoft's solution to this, and it's genuinely useful — but the model has some subtleties that aren't obvious until you run into them in production.

This article walks through how group policy assignment works in Microsoft Teams, how to structure your policies for different user populations, and how to handle the cases that make it complicated.

Direct Assignment vs Group Assignment: The Core Difference

In the Teams Admin Center, every policy type — meeting policies, messaging policies, app permission policies, and so on — can be assigned to users in two ways: directly or through a group.

Direct assignment is when you go to a specific user's profile in the Admin Center and assign a policy to them explicitly. This is easy to reason about, but it doesn't scale. If you need to change the meeting policy for your entire sales team, you're updating records one by one unless you use PowerShell.

Group assignment is when you assign a policy to an Azure Active Directory (Entra ID) group. Every user who is a member of that group inherits the policy. When group membership changes — someone joins the sales team, someone leaves — their policy assignment updates automatically, usually within a few hours.

This is the right model for most organisations. The key insight is that group policy assignment in Teams works through Entra ID security groups and Microsoft 365 groups, not through Teams themselves. You're managing policy membership through HR/IT group membership, which is the right separation of concerns.

How Rank Works When Users Are in Multiple Groups

Here's where it gets interesting. A user can be a member of multiple groups, and those groups can have different policies assigned. When that happens, Teams needs a tiebreaker. That tiebreaker is called rank.

When you assign a policy to a group through group policy assignment, you specify a rank (a positive integer, where 1 is highest priority). If a user belongs to two groups with conflicting assignments for the same policy type, the group with the lower rank number wins.

In practice, most organisations don't have heavily overlapping group assignments, so rank rarely causes confusion. But it's worth understanding before you design your group structure. If you have a "Restricted Users" group with a locked-down meeting policy and a "Project Team" group with an elevated meeting policy, you need to think carefully about which policy should take precedence for users who belong to both.

Setting Up Group Policy Assignment in the Teams Admin Center

To assign a policy to a group, navigate to the policy type in question (for example, Meetings > Meeting policies), then click the "Group policy assignment" tab. From there, click "Add," select the group you want to assign the policy to, choose the policy, and set the rank.

Alternatively, you can do this from the Users section: Users > Group policy assignment shows you all current group policy assignments across all policy types in one view. This is the better overview if you're auditing what's currently configured.

One important caveat: group policy assignment propagation is not instant. After you make a change, it can take several hours before all affected users see the new policy reflected in their Teams client. Don't test by checking the policy five minutes after assigning it. Wait at least a few hours, and use the per-user policy view (Users > [user] > Policies tab) to verify the effective policy for a specific individual.

Designing Your Policy Groups: A Practical Approach

Most organisations end up with somewhere between three and eight distinct Teams policy configurations. The exact breakdown depends on the business, but here's a structure that works well in practice:

Tier 1 — Standard users. This is the Global policy. Most employees get the default configuration. No explicit group assignment needed; they just inherit the Global policy. The key is to set the Global policy intentionally — don't leave it at the Microsoft defaults and assume it's correct for your organisation.

Tier 2 — Restricted users. Frontline workers, contractors, or users in regulated roles who need more limited capabilities. A typical restricted meeting policy might disable meeting recording and transcription. A restricted messaging policy might disable GIFs and external chat.

Tier 3 — Elevated users. IT staff, executives, or power users who need capabilities beyond the standard. An elevated meeting policy might enable recording, bypass the lobby for everyone, and allow external presenters. An elevated messaging policy might enable read receipts reporting or priority notifications.

Tier 4 — Special-purpose users. Compliance officers, legal hold administrators, or users who need specific capabilities for regulatory reasons. These are often the trickiest to design because the requirements come from outside IT.

Map these tiers to Entra ID security groups that your HR or IT provisioning process already manages. If you have an "All Employees" group, that's a natural candidate for the standard policy assignment. If you have department-specific groups (Sales, Finance, Engineering), you can use those for department-level customisation.

Using Policy Packages for Simplified Assignment

Policy packages are bundles of related policies — meeting policy, messaging policy, app setup policy, and so on — pre-configured with settings suitable for a particular user type. Microsoft provides several pre-built packages (Frontline Worker, Education, Healthcare), and you can create custom packages.

The advantage of policy packages over individual policy assignments is simplicity: you assign one thing (a package) instead of many individual policies. The disadvantage is that packages are somewhat less flexible — if you want to customise one policy within a package differently from the others, you either need to override it with a direct assignment or create a new package.

For organisations with a clear set of user populations that differ from each other in consistent ways, policy packages are worth using. For organisations with complex, overlapping policy requirements, individual policy management with group assignment often gives more control.

Using PowerShell for Bulk Operations

The Teams Admin Center is good for ad hoc management and configuration, but PowerShell is better for bulk operations and automation. The MicrosoftTeams module provides cmdlets for everything you can do in the Admin Center, plus some things you can't.

A few commands worth knowing:

# Get a user's current policy assignments
Get-CsUserPolicyAssignment -Identity [email protected]

# Assign a meeting policy to a group
New-CsGroupPolicyAssignment -GroupId <group-object-id> -PolicyType TeamsMeetingPolicy -PolicyName "Restricted-Meeting" -Rank 2

# View all group policy assignments for a policy type
Get-CsGroupPolicyAssignment -PolicyType TeamsMeetingPolicy

# Remove a group policy assignment
Remove-CsGroupPolicyAssignment -GroupId <group-object-id> -PolicyType TeamsMeetingPolicy

Using PowerShell to audit your policy assignments before a migration or configuration change is a good habit. Pulling a full export of user-to-policy mappings as a baseline before making changes gives you a rollback reference if something goes wrong.

Common Pitfalls

Forgetting about nested groups. Group policy assignment in Teams works with direct group members, not with members of nested sub-groups. If your "All Sales" group contains "Sales APAC" and "Sales EMEA" as sub-groups, users in the sub-groups will not inherit a policy assigned to "All Sales." You need to assign the policy to each group individually, or restructure your groups to use flat membership.

Direct assignments from the past overriding group assignments. If someone assigned a policy directly to individual users at some point — perhaps before group assignment was in use — those direct assignments will override group assignments. Run a periodic audit to find users with direct policy assignments and replace them with group-based assignments where appropriate.

Not testing rank logic. Before rolling out a complex group assignment configuration, test it with a small pilot group. Put a test user in two groups with conflicting rank settings and verify that the policy assignment behaves as expected. Rank issues are subtle and can be hard to debug after the fact.

A Note on Policy Propagation Timing

Policy changes in Teams are asynchronous. After you assign or modify a policy, it can take anywhere from a few minutes to a few hours to propagate to all affected users' clients. In practice, most changes are visible within 30–60 minutes, but for large group assignments, it can take longer. Don't assume a change has failed just because it isn't immediately visible.

If you need to verify that a policy assignment has taken effect for a specific user, the most reliable check is the per-user policy view in the Admin Center, not the Teams client itself. The Admin Center reflects the backend state; the Teams client may be cached.