# Managing Teams apps and agents: permission policies, setup and approvals

> Control which Teams apps and agents users can install: org-wide settings, app centric management or permission policies, setup policies and requests.

Source: https://www.epifive.com/blog/teams-app-agent-permission-policies · Published 2026-10-23 · EpiFive

Teams decides whether a person can use an app or agent by combining several controls: org-wide app settings, the status of the individual app, and either per-app user assignment (app centric management) or app permission policies. Which of the last two your tenant uses determines where you work in the Teams admin center. This article explains how the controls fit together, how to allow an app for a subset of users, how to pin apps and control custom app upload with setup policies, and how to handle user requests.

## Who this is for and what you will have at the end

This is for Teams administrators and Microsoft 365 administrators who need to decide which apps and agents their users can install, and who need to explain why a given user can or cannot use one. At the end you will know which governance model your tenant is on, have a default posture for Microsoft, third-party and custom apps, be able to restrict an app to a group, understand how setup policies interact with that, and have a process for approving user requests.

Microsoft's documentation now covers Teams apps and Copilot agents together, and the same controls apply to both. Where this article says "app", agents packaged in a Teams app are included.

## Prerequisites

- The Teams Administrator role in Microsoft Entra ID is enough to manage these settings. Microsoft recommends using the lower-privileged role where possible, even though some higher-privileged roles can also do these tasks.
- Access to the Teams admin center at `admin.teams.microsoft.com`.
- For PowerShell, the MicrosoftTeams module (`Update-M365TeamsApp` and `Get-M365TeamsApp` are part of it).
- For group-based availability, security groups, Microsoft 365 groups, dynamic membership groups, nested groups or distribution lists to point at. Microsoft documents all of these as supported group types for app availability.

## How the controls fit together

To let users use an app or agent, Microsoft's documentation says it must be allowed in several places, and any one of them can block it:

| Layer | Scope | What it does |
| --- | --- | --- |
| Org-wide app settings | Whole tenant | Sets the default for Microsoft, third-party and custom apps |
| App status and availability | Per app | Allowed or blocked, and who the app is available to |
| App permission policy (older model) | Per user | Allows or blocks apps for assigned users |
| App setup policy | Per user | Pins apps, controls custom app upload, and installs apps where app centric management is not in use |
| Microsoft 365 admin center, Integrated apps | Per app | Allow or block agents and apps from the other admin center |

On the last row, Microsoft documents a difference depending on whether your organization has migrated to unified app management. If it has not, allow apps and agents in both the Teams admin center and the **Integrated apps** page in the Microsoft 365 admin center, and keep the two in sync. If it has, you can do it in either place.

The practical rule is that the first two layers decide whether an app is allowed in your organization at all, and the per-user layer decides who gets it.

## Step 1: Decide which model your tenant uses

Microsoft describes two methods for controlling who can use each app:

- **App permission policies**, where a policy contains allow or block rules for Microsoft apps, third-party apps and custom apps, and takes effect only when assigned to a user.
- **App centric management**, where each app carries its own list of users and groups. Microsoft states it replaces app permission policies.

From April 2025, Microsoft states that tenants are automatically migrated to app centric management. Tenants that use only the default Global policy are migrated automatically. Tenants with custom policies have an assisted migration. After migration you cannot revert it, and you cannot access, edit or use permission policies.

To find out which model you are on, open **Teams apps** > **Permission policies** in the Teams admin center. If your tenant has been migrated, the page shows a message saying permission policies no longer apply. If you see policies, you can keep using them or migrate yourself.

Microsoft's manage-apps article goes further and describes permission policies as deprecated, directing you to app centric management for per-user availability. Plan accordingly: if you still depend on permission policies, treat the migration as something to schedule, not avoid.

## Step 2: Set the org-wide defaults

Org-wide app settings define the default for apps you have not actively managed, and for new apps that appear in the Teams store.

1. In the Teams admin center, go to **Teams apps** > **Manage apps**.
2. Select **Actions** > **Org-wide app settings**.
3. Configure the settings in the pane:
   - **Show tailored apps**: when on, users with an F license get the tailored frontline app experience.
   - **Microsoft apps**: a single control that lets users install and use available apps by default.
   - **Third-party apps**: a single control for bulk availability of new and existing third-party apps.
   - **Custom apps**: **Let users install and use available apps by default**.
4. Select **Save**. The settings take effect after a few hours.

Two behaviours matter when you change these toggles.

First, after migration to app centric management the third-party control is one switch. Toggling it on enables all new and existing third-party apps across the tenant, and toggling it off disables all of them. It does not override apps you managed individually.

Second, the org-wide setting does not apply to apps you set to **Specific users and groups** and saved, apps you assigned to **Everyone** or **No one** and saved individually, or blocked apps. So if you set an app to a specific group and later flip the org-wide switch, that app keeps its group assignment.

Built-in Teams agents such as Channel Agent and Facilitator are no longer controlled by the Microsoft apps setting. They are managed from **Teams apps** > **Built-in Teams agents**, where you select an agent and choose **Edit availability** to make it available to everyone, to specific users or groups, or to no one.

A sensible starting posture for most tenants is to leave Microsoft apps on, decide deliberately about third-party apps (off if you want an allow-list model, with approved apps assigned individually), and keep the custom apps default aligned with how much you trust your own developers.

In Microsoft 365 Government environments (GCC, GCC High, DoD), Microsoft documents that all third-party apps are blocked by default.

## Step 3: Allow an app for specific users with app centric management

This is the replacement for building one permission policy per audience.

1. Go to **Teams apps** > **Manage apps** and select the app name.
2. Open the **Users and groups** tab.
3. Under **Select to manage who this app is installed for or available to in your organization**, select **Availability**.
4. Select **Edit availability**.
5. In the **Available to** menu choose one of:

   | Option | Who gets the app |
   | --- | --- |
   | Everyone | All org users, new users and guests |
   | Specific users or groups | Only the users and groups you select; guests cannot use the app, even if assigned |
   | No one | Nobody; equivalent to a blocked app |

6. If you chose specific users or groups, search under **Search for users or groups**, then select **Apply**.

To remove a user or group, select the rows and choose **Remove**.

Limits and behaviours to know:

- You can add up to 99 users or groups at a time to an app.
- The search shows only 20 results, so type the exact name if you do not see what you expect.
- Changes take up to 24 hours, and in rare cases up to six days to reflect in the client.
- You cannot update availability in bulk in the Teams admin center. Use PowerShell for bulk changes.

To see what one person can use, open **Users** > **Manage users**, select the user and open the **Apps** tab. It shows how each app reaches the user: everyone, direct assignment or a group. You can remove direct assignments there, but not availability granted through everyone or a group. Apps assigned to no one and blocked apps are not listed.

### Script it with PowerShell

The MicrosoftTeams module exposes `Get-M365TeamsApp` to read an app's state and `Update-M365TeamsApp` to change it. The `Id` is the app's application ID, and users and groups are identified by their object IDs. The values below are placeholders.

```powershell
Connect-MicrosoftTeams

# Read the current state, availability and installation details
Get-M365TeamsApp -Id 00000000-0000-0000-0000-000000000001

# Make the app available to everyone
Update-M365TeamsApp -Id 00000000-0000-0000-0000-000000000001 -AppAssignmentType Everyone

# Make the app available to specific users and groups (adds to the existing list)
Update-M365TeamsApp -Id 00000000-0000-0000-0000-000000000001 `
    -AppAssignmentType UsersAndGroups `
    -OperationType Add `
    -Users 00000000-0000-0000-0000-0000000000a1 `
    -Groups 00000000-0000-0000-0000-0000000000b1
```

`Get-M365TeamsApp` returns `IsBlocked` (Blocked or Unblocked), an `AvailableTo` property with the assignment type (Everyone, UsersAndGroups or Noone) and the users and groups, who last changed it and when, and an `InstalledFor` property. `-OperationType` accepts Add or Remove. Test any script on a single app before running it across a catalog.

## Step 4: If you still use permission policies

If your tenant still has the permission policies page, the procedure is:

1. Go to **Teams apps** > **Permission policies** and select **Add**.
2. Name the policy and add a description.
3. For each of **Microsoft apps**, **Third-party apps** and **Custom apps**, choose one of:
   - Allow all apps or copilot agents
   - Allow specific apps or copilot agents and block all others
   - Block specific apps or copilot agents and allow all others
   - Block all apps or copilot agents
4. For allow-specific or block-specific, select **Allow apps** or **Block apps**, search (results are filtered to that app category), add the apps and confirm.
5. Select **Save**.

Constraints from Microsoft's documentation that cause most surprises:

- A policy does nothing until it is assigned to a user. Group assignment is not supported for app permission policies, so you assign to users directly (the Teams admin center or PowerShell).
- Edits and assignments take a few hours to take effect.
- After you create a custom policy, you cannot change it if third-party apps are disabled in org-wide app settings.
- To unassign a custom policy from a user, set the policy back to **Global (Org-wide default)**. To remove many assignments, select the policy and use **Manage users** > **Bulk unassign users**, choose **Load data** to see the count, then **Unassign** and **Confirm**.

If you are migrating, the mapping Microsoft documents is straightforward for a single global policy: a blocked app stays unavailable to no one, and an allowed app becomes available to everyone. During automatic migration, one security group is created per custom permission policy, its members are the users assigned to that policy, and those groups are assigned to the apps the policy allowed. After migration you manage those groups like any others.

One conflict case needs attention. If an app is allowed in the Global policy but blocked in a custom policy, auto-migration makes it available to all users of the tenant (except EDU customers, where it is available to none). Review these before migration, not after.

For an assisted migration, start from **Teams apps** > **Permission policies** and select **Get started**, choose the assigned policies to migrate, review the three tabs (available to everyone, to specific users and groups, to no one), resolve conflicts and select **Start migration**. You can save a draft with **Finish later** or discard with **Reset all changes**. App assignments cannot be changed while a migration is in progress.

## Step 5: Use setup policies for pinning and custom app upload

App setup policies work alongside whichever model you use. They cover three things: installing apps on behalf of users (only where you are not on app centric management; otherwise use the Manage apps page), pinning apps, and controlling who can upload custom apps.

Built-in setup policies are **Global (Org-wide default)** and **FirstlineWorker**; the latter cannot be customized.

### Pin apps

1. Go to **Teams apps** > **Setup policies** and select **Add**.
2. Name the policy.
3. Optionally turn on **User pinning** so users can pin their own apps and reorder them.
4. Under **Pinned apps** select **Add apps**, search, and select **Add**.
5. Order the apps independently under **App bar**, **Messaging extensions**, **Meeting extensions** and **Calling extensions**, then **Save**.

Pinning respects other governance controls: if a user is not allowed an app, a pin does not give it to them. Other documented points:

- Admin pins take precedence, and user pins appear below them. Turning off user pinning removes users' own pins.
- At least two apps must be pinned for the Teams mobile client to reflect the policy; with fewer, mobile keeps its existing configuration.
- The in-meeting bar shows two apps, and the rest appear under **More**.
- A pinned calling extension must also be assigned to the users who need it in one-on-one calls.
- You cannot add custom apps with configurable tabs using setup policies.
- Changes take a few hours.

Setup policies, unlike permission policies, support assignment to groups (distribution lists, mail-enabled security groups, security groups and Microsoft 365 groups). A user can have several assignments, but only one policy is effective, based on policy precedence.

### Control custom app upload

Custom apps are built for your organization and are not in the public store. Three settings combine to decide who can upload them:

| Control | Where | Effect |
| --- | --- | --- |
| Org-wide custom app setting | Manage apps > Org-wide app settings | Whether users can interact with uploaded custom apps |
| **Upload custom apps** | App setup policy | Lets assigned users upload custom apps |
| **Allow members to upload custom apps** | Team settings > Member permissions | Per-team switch, controlled by owners and admins |

Microsoft's combined table shows the key cases: if the org-wide setting is off, upload is unavailable regardless of the others. If the org-wide setting is on, the setup policy is on and the team setting is on, any user can upload to the team and personally. If the setup policy is on and the team setting is off, only team owners can upload to the team, though the user can still upload in the personal context. If the setup policy is off, the user cannot upload for their own use. In every case, users can still submit custom apps for admin approval.

To let only selected people upload, keep the org-wide custom app setting on, turn **Upload custom apps** off in the Global setup policy, and create a separate setup policy with it on, assigned to the selected users or groups.

Admins can upload a custom app directly from **Manage apps** with **Upload new app** or **Actions** > **Upload new app**. It becomes available to the organization after a few hours without an approval step, and users find it under **Built for your org** in the Teams store. To update it, use **Upload file** on the app details page; policies applied to the previous version carry over.

Agents must be contained in a Teams app package, they only work if custom app upload is allowed, and any agent in a Teams app works only if an admin allows the app in the organization.

## Step 6: Handle user requests for blocked apps

Users can see blocked apps in the Teams store and request approval. You can see requests on the Teams admin center dashboard, in the **Most requested apps** card, in the **All apps** table (set **Filter by action** to **Apps requests**) and on the **User requests** tab of the app details page.

To act on a request:

1. Open the app details page on the **User requests** tab.
2. Select a request and choose **Approve** or **Deny**, or use **Approve all** or **Deny all**.
3. For **Approve all**, choose **Approve** (availability changes to select users and groups) or **Approve for the organization** (availability changes to Everyone).
4. If the app is blocked, choosing **Approve** offers **Approve and unblock** or **Approve and keep blocked**. If the app stays blocked, the user still cannot use it.

Denied users can request the same app again after a few hours. You can set up a Teams channel alert from **Set up alert** in **Rules**, choosing **Requests to use an app**.

To change the user-facing message, open **Org-wide app settings** and add text (up to 300 characters) under **User requests configuration**, or turn on **Redirect requests to external link** and provide your own URL. User requests are not supported for custom apps or in GCC, GCC High and DoD tenants.

For evaluating an app before you approve it, the **Manage apps** page includes an **Apps to consider allowing** tile counting Microsoft 365 certified and publisher-attested apps, and each app details page has a **Security and Compliance** tab with certification status. You can also export the app catalog as CSV for review by your security team.

## Verification

After a change, allow for the documented delay (a few hours for org-wide settings and policies, up to 24 hours for app availability), then check:

1. In **Manage apps**, filter the app list and confirm the **Available to** column shows what you intended.
2. In **Users** > **Manage users**, open a test user's **Apps** tab and confirm the app appears or does not.
3. Sign in as a test user in the Teams client and search the store. An allowed app shows **Add**; a blocked app shows **Request approval**.
4. Run `Get-M365TeamsApp` for the app and confirm `IsBlocked` and `AvailableTo`.

## Troubleshooting

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| User cannot use an app you allowed | The change has not propagated, or the app is blocked in the Microsoft 365 admin center Integrated apps page | Wait for the documented delay; check both admin centers if not migrated to unified management |
| Guest cannot use an app assigned to them | Guests cannot use apps set to specific users or groups | Set availability to Everyone if guests must have it |
| Permission policies page shows a message instead of policies | The tenant is on app centric management | Manage availability from the app's **Users and groups** tab |
| Cannot edit a custom permission policy | Third-party apps are disabled in org-wide settings | Enable third-party apps in org-wide settings first, or move to app centric management |
| Pinned app does not appear for a user | The user is blocked from the app, or the policy is not assigned | Fix availability first, then check setup policy assignment and precedence |
| Mobile client ignores your pinned apps | Fewer than two apps pinned | Pin at least two |
| Request approved but user still cannot use the app | App is still blocked | Choose **Approve and unblock**, or unblock the app |
| Agent does not work | Custom app upload not allowed, or the app is not allowed | Enable custom app upload and allow the app |
| App shows as **Blocked by publisher** | The publisher requires admin configuration first | Follow the publisher's guidance before allowing |

## Checklist

- Confirm whether the tenant uses app centric management or permission policies.
- Set org-wide defaults for Microsoft, third-party and custom apps deliberately.
- Keep the Teams admin center and Integrated apps settings aligned if not on unified management.
- Assign per-app availability to groups, not individual users, so it is maintainable.
- Review built-in Teams agents on their own page.
- Restrict **Upload custom apps** to a dedicated setup policy.
- Turn on a request alert and review requests regularly.
- Verify with a test user, allowing for propagation time.

Related reading: [Teams external access vs guest access](https://www.epifive.com/blog/teams-external-access-vs-guest-access) covers how guests interact with apps and chats, and [Teams standard vs private vs shared channels](https://www.epifive.com/blog/teams-private-vs-shared-channels) covers channel-level controls that sit next to these app settings.

## References

- Manage app permission policies in Microsoft Teams: https://learn.microsoft.com/en-us/microsoftteams/teams-app-permission-policies
- Manage your apps in the Microsoft Teams admin center: https://learn.microsoft.com/en-us/microsoftteams/manage-apps
- App centric management to manage user access to Teams apps: https://learn.microsoft.com/en-us/microsoftteams/app-centric-management
- Manage agents and app setup policies in Microsoft Teams: https://learn.microsoft.com/en-us/microsoftteams/teams-app-setup-policies
- Manage custom app policies and settings: https://learn.microsoft.com/en-us/microsoftteams/teams-custom-app-policies-and-settings
- User requests for admins: https://learn.microsoft.com/en-us/microsoftteams/user-requests-approve-apps
- Update-M365TeamsApp: https://learn.microsoft.com/en-us/powershell/module/teams/update-m365teamsapp
- Get-M365TeamsApp: https://learn.microsoft.com/en-us/powershell/module/teams/get-m365teamsapp

## Frequently asked questions

### Are Teams app permission policies deprecated?

Microsoft documents app centric management as the replacement for app permission policies, and says tenants are automatically migrated to it starting from April 2025. If your tenant has been migrated, the permission policies page shows a message and you cannot edit policies there. Tenants that still show policies can keep using them or migrate on their own.

### How do I allow a Teams app for only some users?

With app centric management, open the app on the Manage apps page in the Teams admin center, go to Users and groups, choose Edit availability and set Available to to specific users or groups. With permission policies, you create a custom policy that allows the app and assign it to those users, because group assignment is not supported for permission policies.

### How long do Teams app policy changes take to apply?

Org-wide app settings and app permission or setup policy changes take a few hours. App availability changes made under app centric management can take up to 24 hours, and Microsoft notes that in rare cases it can take up to six days for the change to appear in the client.

### Can users ask for an app that is blocked?

Yes. Users can see blocked apps in the Teams store and request admin approval. You review the requests in the Teams admin center on the Manage apps page, then approve or deny them. This is not supported for custom apps or in GCC, GCC High and DoD tenants.