What it does

The per-app access model that replaced app permission policies. Each app (and agent) in the catalogue gets one availability setting — Everyone, Specific users or groups, or No one — set on the app itself in the Manage apps page, rather than building permission policies and assigning them to users.

Key facts

• Three availability options per app: Everyone (all users, new users and guests), Specific users or groups (guests excluded), No one (the old "blocked" state).
• Microsoft began automatically migrating tenants to app centric management from April 2025 (MC688930). Once migrated, the permission policies page and migration wizard are gone and there's no way back.
• Tenants with only the global permission policy were migrated automatically by Microsoft; tenants with custom policies were offered an assisted migration in the Teams admin center.
• Auto-migration created one security group per custom permission policy, added that policy's users to it, and assigned the group to the apps that policy allowed. Those groups are now ordinary groups you can manage.
• Assignment accepts security groups, Microsoft 365 groups, dynamic membership groups, nested groups and distribution lists — up to 99 users or groups per app.
• Org-wide app settings (Manage apps > Actions) carry a "Let users install and use available apps by default" toggle per app type — Microsoft, third-party and custom. It only governs new apps and apps you haven't explicitly managed.
• Changes take up to 24 hours to apply, and Learn says client reflection can occasionally take up to six days.
• PowerShell: Get-M365TeamsApp, Get-AllM365TeamsApps and Update-M365TeamsApp in the MicrosoftTeams module. Bulk changes are PowerShell-only — the UI has no bulk edit.
• The Manage apps page also exposes certification and publisher attestation on a Security and Compliance tab, a CSV export of the whole catalogue, and user app requests via View and manage user requests.
• Built-in Teams agents (Facilitator, Channel Agent and the like) are managed on a separate Built-in Teams agents page and aren't controlled by the Microsoft apps toggle.
• In GCC, GCC High and DoD, all third-party apps are blocked by default.

When to use / skip

You don't really get a choice any more — every tenant is on this model. The question is whether you take the time to rationalise what the migration left behind. If the client had three or four permission policies, auto-migration will have produced a matching set of security groups called something unhelpful, and a lot of apps assigned to them. Worth a tidy-up pass early in any engagement where apps are in scope.

The bigger decision is the org-wide default for third-party apps. Leaving it on is the low-friction route and matches what most tenants had under the old global policy. Turning it off and allowing apps by exception is the right call for regulated clients, but only if someone owns the request queue — otherwise users raise requests that sit unanswered and adoption suffers.

Configuration decisions

• Org-wide default per app type: on (allow by exception to block) or off (block by exception to allow). Third-party is where the debate usually lands.
• Whether custom (line-of-business) apps should be available to everyone on publish, or scoped to a pilot group first.
• Group strategy for scoped apps — reuse existing security groups, or create a dedicated app-<name>-users naming convention. With a 99-assignment cap, use groups rather than individuals.
• Who triages user app requests and on what SLA. Without an owner, don't advertise the request route to users.
• Whether to rename or consolidate the security groups created by auto-migration.
• Whether apps are managed from the Teams admin center or the Microsoft 365 admin center integrated apps experience — pick one as the source of truth so they don't drift.

Gotchas

• The 99-assignment limit is per app. Assigning individual users eats it fast; use groups from day one.
• Search in the availability picker only returns 20 results. Type the exact group name.
• You can't remove a user from an app's assignment if they got it through "Everyone" or a group — the Apps tab on the user's page tells you which route applies.
• Apps migrated from "blocked" show a status of unblocked but are assigned to No one. Reports filtering on status alone will mislead you.
• Auto-migration treated apps that were allowed in the global policy but blocked in a custom policy as available to all users (EDU tenants got the opposite). If a client relied on a custom policy to keep an app away from a population, check it survived.
• Admin consent to app permissions carried over through migration — so it's worth reviewing what Graph permissions old apps still hold.
• The 24-hour propagation means "I've just allowed it, try now" isn't a support answer. Set expectations before the change window.

Consultant notes

• Export the catalogue CSV at the start of the engagement and again at handover — it's the cheapest audit trail you'll get.
• Script app availability with Update-M365TeamsApp for any rollout touching more than a handful of apps; the UI is fine for one-offs only.
• Use the popular apps widget as a conversation starter with the client: it shows heavily used third-party apps that aren't yet available to everyone.
• Setup policies (install and pin) still exist and are separate — availability decides whether a user can have an app, setup policy decides whether it's put in front of them.
• Copilot and agent availability goes through the same Manage apps page, but the decisions about agents belong in the Copilot workstream.

---

Worth revisiting if Microsoft lifts the 99-assignment limit or folds Teams app management fully into the Microsoft 365 admin center