Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for Microsoft Teams By James Joyner IV · · 8 min read

Microsoft Teams Error: 'This app has been blocked by your IT admin' — Cause, Fix, and Troubleshooting Guide

Quick answer

Fix Teams 'This app has been blocked by your IT admin': allow the app in org-wide settings and the user's app permission policy, then approve and assign.

  • #microsoft-teams
  • #troubleshooting
  • #errors
  • #app-manifest
Free toolkit

Fixing errors like this? Get 500 free DevOps AI prompts

500 copy-paste AI prompts for the stack you actually run — one PDF, free.

Overview

An end user tries to open or install an app and is stopped with a message that their administrator has blocked it, or the app simply doesn’t appear in their app list. This is an app governance decision applied through org-wide app settings and/or the user’s app permission policy, not a fault in the app itself.

This app has been blocked by your IT admin.

Symptoms

  • The user sees an explicit “blocked by your IT admin” message when opening or adding the app.
  • The app is missing entirely from the user’s Teams app list or store search.
  • The app is visible but greyed out and can’t be installed or launched.
  • Some users can use the app while others in the same tenant cannot.
  • A newly published custom app never shows up for anyone pending approval.

Common Root Causes

  • App set to Blocked in org-wide app settings — the tenant-wide control blocks the specific app for everyone.
  • App permission policy blocks it — the policy assigned to the user blocks that app individually, or blocks its category (Microsoft, third-party, or custom apps) as a group.
  • Custom app not yet approved — a sideloaded/published custom app is pending review in the org app catalog and isn’t allowed until approved.
  • Publisher or category block — a broad “block all third-party apps” or “block all custom apps” stance catches the app even though it was never named directly.
  • Wrong policy in effect — the user is on a restrictive policy rather than the permissive one you edited.
  • Propagation lag — an allow decision is correct but hasn’t reached the user yet.

How to diagnose

Check the two governance layers that can block an app: org-wide app settings and the app permission policy assigned to the user. In the Teams admin center these are under Teams apps → Manage apps (per-app allow/block and org-wide settings) and Teams apps → Permission policies.

For scripted checks, you can read the app’s catalog state and the effective policy through Microsoft Graph and the Teams admin tooling:

# Look up the app in the tenant app catalog to see its state
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/appCatalogs/teamsApps?\$filter=displayName eq 'Contoso Ops'" | jq .

Confirm three things: the app is Allowed (not Blocked) in Manage apps, the user’s assigned app permission policy allows that app and its category, and any custom app has been approved in the catalog.

Fixes

Unblock at both layers, in order:

  1. In Teams admin center → Teams apps → Manage apps, find the app and set its status to Allowed. If it’s a custom app pending review, approve/publish it here first.
  2. Confirm org-wide app settings aren’t blocking the whole category the app belongs to (Microsoft, third-party, or custom).
  3. Edit the app permission policy assigned to the affected users so the app — and its category — is allowed rather than blocked.
  4. Assign the corrected permission policy to the user or their group if they weren’t already on it.

Keep the change scoped. Prefer allowing the specific app for the group that needs it over relaxing the org-wide category block for everyone. After allowing and assigning, let the change propagate — it can take time to reach clients — then have the user restart Teams so the store and app list refresh.

What to watch out for

  • Two layers, both must pass — an allow in the permission policy won’t help if the app is Blocked org-wide, and vice versa; fix both.
  • Category blocks are silent — “block all third-party/custom apps” catches apps you never named individually.
  • Approval is separate from allow — a custom app must be approved in the catalog before an allow policy matters.
  • Effective policy — verify which permission policy the user actually has; editing the wrong one changes nothing.
  • Propagation delay — don’t call it broken for a while; policy changes aren’t instant.
  • Blast radius — scope allow decisions to the group that needs the app instead of loosening tenant-wide controls.
Free download · 368-page PDF

Get 500 Battle-Tested DevOps AI Prompts — Free

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.