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.
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:
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.
For a straightforward app, the essential manifest change is conceptually limited to two fields:
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:
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.
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
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.
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.
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.
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.
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:
- 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.
- 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.
- Identify whether the app needs to run inside private or shared channels. Those experiences are where manifest 1.25 and
supportsChannelFeaturesbecome operationally important. - 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.
- 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.
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 issupportsChannelFeatures, 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:
Code:
{
"manifestVersion": "1.25",
"supportsChannelFeatures": "tier1"
}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.
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
supportsChannelFeaturesappropriately, 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.
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
- 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 - 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 - 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