Teams Manifest 1.25 Required for New Channel Apps in July 2026

Microsoft’s July 2026 requirement does not force every internally deployed Teams app onto manifest 1.25. The immediate submission gate applies to new Teams Store submissions for channel-enabled apps; tenant-only custom apps and personal-scope message extensions sit on different branches of the decision tree.
That distinction matters because “Teams app” can describe everything from a Marketplace product installed by thousands of organizations to a ZIP package uploaded for one tenant. Microsoft Learn documents the Store requirement alongside separate single-tenant distribution routes, so administrators should classify the app before scheduling repackaging work.

Start With Distribution, Then Check Channel Scope​

The first question is not whether an app runs in Teams. It is where the package is going.
Microsoft states that, starting in July 2026, all new Teams Store submissions for channel-enabled apps must use manifest schema version 1.25 or later. This is Marketplace-facing language, not a blanket retirement notice for every older manifest already deployed in Microsoft 365 tenants.
Use this applicability check:

1. Determine whether the package is being submitted as a new app to the Teams Store. If it is not, the stated July submission rule does not directly apply.
2. Check whether the app is channel-enabled rather than exclusively personal. A Store submission without channel capabilities is outside the specific wording of this requirement.
3. Identify whether the app needs to run inside private or shared channels. Those experiences are where manifest 1.25 and supportsChannelFeatures become operationally important.
4. Audit the app’s dependencies on team membership, channel membership, files, cross-channel data, and user type. These dependencies determine whether the migration is a manifest edit or a larger application change.
5. Validate and test the final package before submission. Changing the schema declaration alone does not prove that the app behaves correctly within a restricted or cross-organizational channel.

A Marketplace publisher preparing a new channel-enabled listing should treat 1.25 as required now. A company maintaining an app exclusively in its own tenant should treat it as an engineering-readiness decision unless another validation or platform requirement applies to that deployment.
Microsoft documents several single-tenant paths: submitting an app to an organization from Teams, publishing through Teams Developer Portal, uploading through Teams admin center, and deployment through Microsoft 365 admin center. These routes remain distinct from a new Teams Store submission.
That does not mean tenant-only developers should ignore 1.25. It means the reason to migrate is compatibility with channel features, not an assumption that the Store rule automatically governs the organization’s private app catalog.

---

The Smallest Manifest 1.25 Migration Is Actually Small​

Manifest 1.25 became generally available in January 2026. Its central channel-related addition is supportsChannelFeatures, an opt-in declaration for Microsoft’s newer channel capabilities, including shared and private channels.
For a straightforward app, the essential manifest change is conceptually limited to two fields:

{
  "manifestVersion": "1.25",
  "supportsChannelFeatures": "tier1"
}

This is only the relevant migration fragment, not a complete Teams manifest. Existing identifiers, capabilities, scopes, URLs, icons, permissions, and version metadata still need to remain valid in the complete package.
Microsoft says the simple route applies when the app does not depend on:

• Team or channel membership for permissions, task assignment, or message delivery.
• Files stored in Teams or SharePoint.
• Data combined or shared across channels or teams.
• Different treatment for internal users, guests, or external participants.

If all four statements are true, Microsoft’s documented work is to set supportsChannelFeatures to tier1 and verify the app across channel types. That is closer to a compatibility declaration plus testing than a redesign.
The testing requirement is the part teams should not abbreviate. A tab rendering successfully in a standard channel says little about whether it selects the correct users, files, authentication context, or data boundary in a private or shared channel.
WindowsForum previously covered the arrival of tabs, bots, and message extensions directly inside Teams private channels. Manifest 1.25 is the packaging and declaration side of that broader platform change: Microsoft is asking publishers to explicitly signal readiness instead of assuming that a team-scoped app will behave correctly everywhere.

Channel Awareness Turns a Schema Edit Into an Application Audit​

The migration becomes more substantial when application logic assumes that a channel and its parent team contain the same users or share the same resources. That assumption is unsafe in private and shared channels.
A private channel can expose the app to only a selected subset of the parent team. A shared channel can introduce collaboration boundaries that differ from ordinary team membership. An app that assigns work, presents records, or calculates permissions from the parent team’s roster therefore needs more than tier1 in its JSON.
File handling deserves the same scrutiny. If an app reads or writes files, developers must verify that it uses the appropriate storage context rather than silently falling back to assumptions built around a standard channel. Cross-channel dashboards and reports also need review so that information from a restricted space is not displayed in a broader one.
User classification is another dividing line. Any feature that changes according to whether someone is an internal employee, guest, or external participant should be tested with those identities rather than simulated with several ordinary tenant accounts.
The practical audit should trace each feature from input to authorization to storage to output. For every bot command, tab view, message-extension action, notification, and background process, record which team, channel, tenant, user, and file context the code trusts.
Manifest 1.25 declares support; it does not create correct authorization logic. Publishers remain responsible for proving that the application respects the narrower membership and data boundaries of each channel.

Personal Message Extensions Have a Clear Exemption​

An app does not become channel-enabled merely because its users can invoke it while using Teams. Scope matters.
Microsoft specifically says that message-extension-only apps operating exclusively in personal scope do not require updates merely to be available to users in shared and private channels. Those apps should not be swept into a migration project solely because employees may use their personal experience while participating in those channels.
This exemption is narrow. It applies to message-extension-only apps that operate exclusively in personal scope. If the package also declares team or channel capabilities, or if its behavior relies on channel context, the team should repeat the full applicability audit rather than relying on the personal-scope exception.
This is also a useful cleanup opportunity. Organizations often have manifests that accumulated scopes during development even though the production app no longer needs them. Removing an unnecessary channel-facing capability can be safer and simpler than declaring support for an experience the application does not truly use.

---

Existing Store Listings Remain the Documentation Gap​

Microsoft’s published wording is precise about new Teams Store submissions. It does not, in the supplied guidance, establish that every existing Store listing must immediately be repackaged, nor does it fully explain how an update or resubmission of an existing listing will be classified.
Publishers should not convert that silence into an exemption. An existing app may eventually need a Store update for an unrelated feature, bug fix, or metadata change, at which point validation could require the current schema for a channel-enabled package. Microsoft’s available statement does not provide enough detail to say exactly where that boundary falls.
The defensible approach is to separate immediate compliance from release risk. New channel-enabled Store submissions need 1.25 now. Existing listings should be inventoried and prepared so that a future submission is not delayed by an untested schema and channel migration.
Store publishers should keep three artifacts ready: a manifest 1.25 branch, a test record covering standard, private, and shared channels, and a documented list of membership, storage, identity, and cross-channel assumptions. That turns a future validation requirement into a controlled release task rather than an emergency investigation.
Tenant-only app owners have more flexibility, but they should still document why an app remains on an earlier schema. “Not going to the Store” answers the submission question; it does not answer whether users need the newer private and shared channel experience.

A July Audit Should End With One of Three Decisions​

Every Teams app owner should be able to place each package into a concrete disposition before the next release:

• A new Teams Store submission with channel capabilities should move to manifest 1.25, declare supportsChannelFeatures appropriately, complete channel testing, and pass Developer Portal validation.
• A tenant-only custom app is not directly captured by the stated Store gate, but should migrate if private or shared channel support is required or planned.
• A message-extension-only app confined to personal scope does not need an update merely because users also participate in private or shared channels.

Apps that cannot fit cleanly into one of those outcomes need engineering review. The most common reason will be hidden dependence on team membership, files, cross-channel aggregation, or user identity rather than the manifest syntax itself.
Administrators should also align this work with their broader Teams app controls. A technically correct package can still be unavailable when tenant policy blocks custom applications, restricts installation, or requires organizational approval. Schema readiness and administrative permission are separate gates.
The July 2026 change is therefore narrower than a universal upgrade mandate but more consequential than a version-number bump. Marketplace publishers of channel-enabled apps must act now, while internal app teams should use manifest 1.25 as a deliberate compatibility choice—and verify the channel boundaries before claiming support.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Publish App for Microsoft 365 & Outlook - Teams | Microsoft Learn

   Learn to make your Microsoft 365-enabled Teams apps discoverable to users in Teams, Outlook, and Microsoft 365 app via single tenant and multitenant distribution.

   learn.microsoft.com
2. Independent coverage: devblogs.microsoft.com
   
   

   Publish your apps to the Microsoft Teams store - Microsoft 365 Developer Blog

   When you publish your SaaS offering to the Microsoft Teams store, you can reach more than 500,000 organizations, including small and large corporations and educational institutions.

   devblogs.microsoft.com
3. Primary source: WindowsForum
   
   

   Teams Private Channels Now Support Tabs, Bots, and Message Extensions (2026) | Windows Forum

   Microsoft launched support for adding Teams apps—tabs, bots, and message extensions—directly to Private Channels for worldwide standard Microsoft 365...

   windowsforum.com

 

[ChatGPT]

Teams developers do not need to upgrade every app manifest to version 1.25 simply because Microsoft’s July 2026 Teams Store rule is now in effect. The immediate work belongs to teams with a new Teams Store submission planned for an app that can operate in channels—especially where shared or private channels are in scope—while existing Store listings and tenant-only deployments should be triaged rather than reflexively repackaged.
Microsoft’s Teams manifest documentation draws a narrower line than the headline suggests: starting in July 2026, new Teams Store submissions for channel-enabled apps must use manifest schema 1.25 or later. That is a submission gate, not a published mandate to migrate every Teams app already installed inside an organization.
For IT administrators, the practical decision is therefore about inventory and release plans. Find the apps headed to the public Store, identify whether they are channel-enabled, and determine whether their channel design extends beyond standard channels. Everything else can be scheduled according to business need, testing capacity, and the app’s normal maintenance cycle.

The July gate is a Store-submission rule, not a tenant-wide deadline​

The first category needing immediate review is straightforward: an app that will be submitted as a new listing in the Teams Store and is designed to work in Teams channels. If that description fits, the package should be moved to manifest schema 1.25 or later before the submission is prepared.
That distinction matters because many organizations use Teams apps in more than one way. A line-of-business app may be uploaded only to a tenant app catalog, distributed directly to selected users, or sideloaded for development and testing. Microsoft’s stated July requirement does not describe those routes as a blanket forced migration target.
Existing Teams Store listings also deserve a calmer reading. The requirement Microsoft documents is for new Teams Store submissions. It does not say that an app already listed in the Store must be immediately republished solely to change its manifest schema version. Teams owners should still monitor the app’s future update plans, but an existing listing is not automatically an emergency migration project based on the available guidance.
This is why “upgrade every Teams app now” is the wrong operational response. It converts a targeted Store-compliance task into an unnecessary portfolio-wide release program, complete with regression-testing risk and potential disruption for apps that may never need channel capabilities outside the standard model.

---

Start with the app inventory that changes a release decision​

The quickest useful audit is not a deep code review. It is a short classification exercise that produces a defensible release queue. Microsoft’s documentation makes channel support and submission path the two decision points that matter most.

1. List every Teams app your organization owns, maintains, or sponsors, including vendor-built custom apps and internally developed packages.
2. Record each app’s distribution route: new Teams Store submission planned, existing Teams Store listing, tenant-only app catalog deployment, or development and sideloaded testing package.
3. Identify whether the app has team scope and whether users can add or use it in a channel. Do not assume that a bot or tab is channel-capable merely because it runs in Teams.
4. For apps headed to a new Store submission, inspect the manifest schema version. A channel-enabled submission that is below 1.25 belongs in the immediate remediation queue.
5. For apps intended to support shared or private channels, inspect the manifest for the channel-capability declaration: supportsChannelFeatures with the value tier1.
6. Test the app against the channel types it claims to support before submitting or updating it. Standard-channel success is not proof that shared- or private-channel behavior will work correctly.

The result should be a small number of distinct buckets rather than one undifferentiated “Teams manifest upgrade” project:

• A new Store-bound channel app needs manifest 1.25 or later now.
• A new Store-bound app without the relevant channel use case should be assessed against its actual capabilities rather than upgraded by assumption.
• An existing Store listing can be placed on a planned maintenance track unless a new submission workflow or channel expansion changes its status.
• A tenant-only or sideloaded app should be tested and upgraded when its own deployment, channel-support, or lifecycle requirements justify the work.

That final category is particularly important in enterprises. Internal-only status does not make an app immune to technical debt, but it does mean Store policy and tenant deployment policy are separate questions. The Teams platform team should avoid letting a public marketplace validation rule silently become an internal release deadline.

Standard channels are the baseline; shared and private channels are the design fork​

The real technical dividing line is not merely “channels” in the broadest sense. Microsoft states that apps with team scope support standard channels by default. Shared and private channel support, however, requires the relevant manifest capability declaration and appropriate testing.
For manifest 1.25, that declaration is:
"supportsChannelFeatures": "tier1"
This field should be treated as a product commitment, not a decorative metadata update. Adding it tells Teams and the Store review path that the app is intended to handle the channel feature set associated with shared and private channels. The app must therefore be evaluated in those settings rather than tested only in a conventional standard channel.
That is where many app inventories need a second pass. A team may describe an app as “channel-enabled” because it includes a tab or collaboration surface, yet its workflow may rely on assumptions that only hold in standard channels. Access patterns, membership expectations, installation behavior, and the app’s own configuration logic can all require attention when the target is a shared or private channel.
Microsoft’s documentation does not turn tier1 into a promise that every application workflow will automatically work everywhere. It establishes the manifest capability required for the support model. The responsibility for validating the app’s actual behavior remains with the publisher and, for internal apps, the organization that owns the deployment.
WindowsForum readers tracking the broader rollout should also separate the platform capability from the new Store gate. Teams support for private-channel apps and the Store manifest requirement are related operationally, but they answer different questions: one concerns where an app can be used; the other concerns what a new public submission must declare.

---

Store publishers should treat 1.25 as a release-readiness checkpoint​

For developers preparing a new Teams Store package, manifest 1.25 should be integrated into the submission checklist early enough that it does not become the final blocker. The most efficient sequence is to update the manifest, verify the channel scope and capabilities, then test in the exact channel types the app will support.
A useful review conversation between developers, product owners, and Teams administrators should answer four concrete points:

• The app has a genuine new Teams Store submission planned, rather than an internal deployment or an already-published listing.
• The app can be used in Teams channels and the channel scenario is part of the product’s supported design.
• Shared or private channel support is explicitly intended, in which case supportsChannelFeatures is set to tier1.
• Testing covers standard channels by default and expands to shared and private channels when that support is declared.

This approach also keeps Store readiness from being confused with modernization for its own sake. Updating the schema may be appropriate for an internal app that is evolving, but the priority should come from a defined deployment event or feature requirement—not from a vague fear that Teams will stop loading an older package everywhere.

The biggest risk is an overbroad migration—and an under-tested narrow one​

There are two avoidable mistakes. The first is launching a mass manifest conversion without identifying which apps are subject to the Store rule. That can consume developer and QA time while creating changes to stable apps whose distribution route is entirely internal.
The second is treating the required schema update as the entire job for a Store-bound channel app. A version number and a capability declaration can satisfy a packaging requirement while leaving untested user flows in shared or private channels. In that scenario, the submission may be technically aligned with the stated rule but operationally incomplete.
Administrators should also keep ownership clear. The people who manage Teams app permissions and catalog distribution may not own the manifest source files, while the development team may not know whether an app is destined for the public Store, an internal catalog, or both. A compact inventory that identifies publisher, distribution route, manifest version, channel scope, and channel test status will expose those gaps quickly.
Microsoft’s guidance is precise enough to drive the first pass, but not broad enough to justify assumptions beyond it. There is no stated universal deadline here for every legacy Teams app. There is, however, a current requirement that can derail a new Store release if the team discovers it only at submission time.

Frequently Asked Questions​

Do existing Teams Store apps have to move to manifest 1.25 immediately?
Microsoft’s documented requirement applies to new Teams Store submissions for channel-enabled apps. It is not stated as a forced migration requirement for every existing Store listing.
Do tenant-only custom Teams apps need manifest 1.25 in July 2026?
The Store submission rule does not, by itself, establish a blanket deadline for apps distributed only within an organization. Evaluate those apps based on planned changes, channel requirements, and normal maintenance priorities.
When is supportsChannelFeatures: "tier1" relevant?
It is the manifest capability declaration for shared and private channel support. Apps with team scope support standard channels by default, but shared and private channel support requires the relevant declaration and testing.
Should a standard-channel app be tested in private and shared channels anyway?
Only if the organization intends to support those channel types. If it does, test the actual workflows there rather than assuming standard-channel behavior carries over.
The immediate milestone is not a universal manifest rewrite; it is the next new Teams Store submission for a channel-enabled app. Teams owners who classify that small but important set now can meet Microsoft’s July 2026 requirement without turning a focused compliance check into an unnecessary migration campaign.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Teams Manifest | Microsoft Learn

   Learn about Teams app manifest requirements, permissions, and sideloading process for app installation.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Teams Manifest 1.25 Required for New Channel Apps in July 2026 | Windows Forum

   Microsoft’s July 2026 requirement does not force every internally deployed Teams app onto manifest 1.25. The immediate submission gate applies to new Teams...

   windowsforum.com