Teams app permission policies design

Microsoft Teams has a vast app ecosystem — thousands of third-party apps plus custom internal apps. Without governance, users install whatever they want; the tenant fills with apps, including risky ones. Teams app permission policies and app setup policies are the admin controls that keep app sprawl manageable.

App permission policies

An app permission policy controls which apps users can install:

App categories

Apps are categorised:

• Microsoft apps — first-party (Planner, Forms, Lists, Forms, etc.).
• Third-party apps — published in the Teams Store.
• Custom apps — your tenant's internal apps.

Policy options

For each category, choose:

• Allow all apps — permissive.
• Allow specific apps and block all others — allow list (only specified allowed).
• Block specific apps and allow all others — block list (only specified blocked).
• Block all apps — restrictive.

A typical balanced policy:

• Microsoft apps — Allow all.
• Third-party apps — Allow specific (an approved-app list curated by IT).
• Custom apps — Allow all (tenant-internal, already vetted by you).

Assignment

Assign per-user or per-group. Different populations get different policies:

• General users — restricted third-party access.
• Specific teams (sales, marketing) — allow specific third-party apps relevant to their work.
• IT and security team — fewer restrictions for testing and evaluation.

App setup policies

An app setup policy controls which apps are pinned by default in the user's Teams sidebar — visual prominence without install action:

• Default pinned apps — Activity, Chat, Teams, Calendar, etc.
• Custom pinned apps — pin your internal LOB app, an approved third-party app for the user's role.
• Allow / restrict user-pinning — can users themselves change the pinning.

Different setup policies per role surface different apps:

• Sales reps — pin your CRM Teams app.
• HR team — pin HR tools.
• Engineering — pin DevOps tools.
• Executives — pin Power BI app.

App-centric management

The newer app-centric management experience in the Teams admin centre lets you manage apps per-app:

1. Find the app in the app catalogue.
2. Set who can install it — specific users / groups, all users, no users.
3. Who has it pre-pinned for fast access.

This per-app management complements policy-based management for surgical control.

OAuth consent governance

Teams apps often request Microsoft Graph permissions the user has to consent to. Combined with Entra ID app consent policies:

• Restrict which Graph scopes users can consent to.
• Risky scopes require admin consent via the admin consent workflow.
• Defender for Cloud Apps alerts on suspicious OAuth grants.

This three-layer governance (Teams policies + Entra consent policies + Defender monitoring) prevents the most common Teams app risks.

Permissions audit

Periodically inventory:

• Which Teams apps are installed tenant-wide (via the admin centre).
• What permissions each has been granted.
• Usage statistics — apps that nobody uses are candidates for blocking.

For Microsoft 365 customers with significant Teams usage, this inventory is worth running quarterly.

App approval workflow

For organisations wanting users to request apps they want installed:

• Custom approval flow — Power Automate flow that captures requests, routes to IT, posts result to user.
• Microsoft 365 admin centre approval (when supported for the app type).

Better than "no" by default with no path to "yes" — users with a real need get approval; users without don't.

Operational considerations

• Document the approved app list so users know what's available.
• Communicate changes — adding or removing apps from the allow list should be announced.
• Regular review — app catalogue changes; existing approvals should be re-validated periodically.
• Pilot new apps before broad rollout.

For tenants approaching Teams app sprawl, deploying explicit policies is the right correction. For new tenants, start with policies in place rather than fixing it later.