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

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:

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.

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:

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

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 covers how guests interact with apps and chats, and Teams standard vs 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