Teams Store validation guidelines

Following these guidelines increases the chances of your app to pass the Microsoft Teams Store submission process. The Teams-specific guidelines complement the Microsoft commercial marketplace certification policies and are updated frequently to reflect new capabilities, user feedback, and business rule changes.

Note

• Some guidelines may not be applicable to your app. For example, if your app doesn't include a bot, you can ignore bot-related guidelines.
• We've cross-referenced these guidelines to the Microsoft commercial certification policies and added Do’s and Don’ts with examples from pass or fail scenarios encountered in our validation process.
• Certain guidelines are marked as Mandatory Fix. If your app submission doesn't meet these mandatory guidelines, you'll receive a failure report from us with steps to mitigate. Your app submission will pass Teams Store validation only after you have fixed the issues.
• Other guidelines are marked as Suggested Fix. For an ideal user experience, we suggest that you fix the issues, however, your app submission will not be blocked from publishing on the Teams Store, if you choose not to fix the issues.

Value proposition

This section is in line with Microsoft commercial certification policy number 1140.1 and provides more guidance to developers of Microsoft Teams apps on their offer’s value proposition.

Apps must provide value to the users by enabling them to complete functional workflows that encourage repeated use. Expand the following sections to know more about the value proposition:

Tabs

Tabs must provide value beyond hosting an existing website. [Mandatory Fix]

Notification bots

A notification provides value in Teams if:

1. Posted card or text provides adequate details requiring no further user action.
2. Posted card or text provides adequate preview information for a user to take action or decide to view further details in a link opening outside Teams.

Apps that provide only notifications with content such as, You have a new notification or click to view, and require the user to navigate outside Teams for everything else don't provide significant value within Teams.

Message extensions

[Mandatory Fix]

Apps that consist of search-based message extension provide user value by sharing cards that allow for contextual conversations without context switching.

To pass validation for a search-based message extension only app, the following are required as baseline to ensure that the user experience isn't broken. A card shared via a message extension provides value in Teams if:

1. Posted card provides adequate details requiring no further user action.

2. Posted card provides adequate preview information for a user to take action or decide to view further details in a link opening outside Teams.

   

   

Link unfurling

Link unfurling only apps don't provide significant value within Teams. Consider building more workflows in your app, if your app only supports link unfurling and has no other functionality.

Back to top

App Name

[Mandatory Fix]

This section is in line with Microsoft commercial certification policy number 1140.1.1 and provides more guidance to developers on naming their apps.

Expand to know more

An app's name plays a critical role in how users discover it in the Teams Store. Use the following guidelines to name an app:

• The name must include terms relevant to your users. [Mandatory Fix]

• Prefix or suffix common nouns with the developer's name. For example, Contoso Tasks instead of Tasks. [Mandatory Fix]

• Must not use Teams or other Microsoft product names such as Excel, PowerPoint, Word, OneDrive, SharePoint, OneNote, Azure, Surface, and Xbox that could falsely indicate co-branding or co-selling. For more information about referencing Microsoft software products and services, see Microsoft Trademark and Brand Guidelines. [Mandatory Fix]

• Must not copy the name of an app listed in the Teams Store or other offer in the commercial marketplace. [Mandatory Fix]

• Must not contain profane or derogatory terms. The name also mustn't include racially or culturally insensitive language. [Mandatory Fix]

• Must be unique. If your app (Contoso) is listed in the Teams Store and Microsoft AppSource and you want to list another app specific to a geography such as Contoso Mexico, your submission must meet the following criteria:

  • Call out the app's region-specific functionality in the title, metadata, first response app experience, and help sections. For example, title must be Contoso Mexico. App title must clearly differentiate an existing app from the same developer to avoid end-user confusion. [Mandatory Fix]
  • When uploading the app package in Partner Center, select the right Markets where the app is available in the Availability section. [Mandatory Fix]

• App name mustn't lead with a core Teams feature such as Chat, Contacts, Calendar, Calls, Files, Activity, Teams, and Help. The app name doesn't shortens to either Chat, Contacts, Calendar, Calls, Files, Activity, Teams, and Help on install in the left navigation. [Mandatory Fix]

• If your app is part of an official partnership with Microsoft, the name of your app must come first. For example, Contoso connector for Microsoft Teams.

• The app name mustn't have any reference to Microsoft or Microsoft products. Don’t use Teams or Microsoft, in the app name unless your app is in official partnership with Microsoft. In such an instance, the app name must come first before any reference to Microsoft. For example, Contoso connector for Microsoft Teams. [Mandatory Fix]

• Don’t use parenthesis in naming to include Microsoft products. [Mandatory Fix]

• Developer name must be the same in the app manifest (previously called Teams app manifest) and AppSource. [Mandatory Fix]

• App manifests submitted must be production manifests. Accordingly, app name mustn't indicate that the app is a preproduction app. For example, app name mustn't contain words such as Beta, Dev, Preview, and UAT. [Mandatory Fix]

• The app name in the app manifest and AppSource must match. [Mandatory Fix]

Tip

Your app’s branding on the Teams Store and AppSource including your app name, developer name, app icon, AppSource screenshots, video, short description, and website either separately or taken together mustn't impersonate an official Microsoft offering unless your app is an official Microsoft 1P offering.

Duplicate App

• Apps from the same developer offering the same functionality must share an app listing unless privacy compliance requirements mandate separate app listings or separate app listing are required to support government cloud. You must build into your business logic and publish only one listing. [Mandatory Fix]

  • To fulfill multiple regions support requirement, you must build into your business logic and publish only one listing.

  

  • To fulfill multiple end-point requirements for on-premises and on-cloud deployment, you must build into your business logic and publish only one listing.

Suitable for workplace consumption

[Mandatory Fix]

This section is in line with Microsoft commercial certification policy number 1140.1.2, 100.8, and 100.10 and provides additional guidance to developers on building workplace appropriate apps.

Expand to know more

App content must be suitable for general workplace consumption and follow all restrictions listed in the commercial marketplace certification policies. Content related to religion, politics, gambling, and prolonged entertainment is prohibited. [Mandatory Fix]

Your app must enable group collaboration, improve an individual's productivity, or both. Apps intended for team bonding and socializing must be collaborative and designed for multiple participants. The apps mustn't require a substantial time investment of over 60 mins per session or affect productivity. [Mandatory Fix]

Content aggregator apps must have a mechanism for users to report an issue or inappropriate content to the app publisher. [Mandatory Fix]

Similar platforms and services

[Mandatory Fix]

This section is in line with Microsoft commercial certification policy number 1140.1.3.

Apps must focus on the Teams experience and not include the names, icons, or imagery of other similar chat-based collaboration platforms or services within the app content or in the app’s metadata unless the app provides specific interoperability.

Feature names

App feature names in buttons and other UI text mustn't use terminology reserved for Teams and other Microsoft products. For example, Start meeting, Make call, or Start chat are feature names in use by Microsoft in Microsoft Teams. If necessary, include your app name to make the distinction clear, such as Start Contoso meeting.

Authentication

[Mandatory Fix]

This section is in line with Microsoft commercial certification policy number 1140.1.4 and provides guidance to developers on authenticating their apps with external services.

For more information on how to implement app authentication, see authentication in Teams.

Expand to know more

Authenticating with external services

If your app authenticates users with an external service, follow these guidelines:

• Sign in, sign out, and sign up experiences:

  • Apps that depend on external accounts or services must provide clear and simple sign in, sign out, and sign up experience. [Mandatory Fix]
  • When users sign out, they must sign out only from the app and remain signed in to Teams. [Mandatory Fix]
  • Apps that depend on external accounts or services must provide a way forward for new users to sign up or contact the app publisher to learn more about the services and get access to the services. Way forward must be available in the app’s manifest, AppSource long description, and app first run experience (bot welcome message, tab setup, or config page). [Mandatory Fix]
  • Apps that require tenant admin to complete one-time setup must call out dependency on tenant admin to configure the app (before any other tenant user can install and use the app). Dependency must be called out in the app’s manifest, AppSource long description, all first run experience touchpoints (bot welcome message, tab setup, or config page), help text as considered necessary as part of bot response, compose extensions, or static tab content. [Mandatory Fix]

• Content sharing experiences: Apps that require authentication with an external service to share content in Teams channels must clearly state in the help documentation (or similar resources) on how to disconnect or unshare content if that feature is supported on the external service. This doesn't mean the ability to unshare content must be present in your Teams app.

Audio

• If the primary intent of the app is to listen to music, it must support at least one collaborative scope with end-to-end workflow specific to app. For example, sharing of playlist, configuring or pinning playlist, and synchronously listening to music. [Mandatory Fix]

• Apps published with the primary intent of letting users listen to music in Teams are recommended to include collaborative co-listening experience. [Suggested Fix]

Security

This section is in line with Microsoft commercial certification policy number 1140.3.

Back to top

Financial information

[Mandatory Fix]

This section is in line with Microsoft commercial certification policy number 1140.3.1 and provides guidance on transmission of financial information within the Teams interface and notifies developers of restricted payment scenarios on the mobile (Android and iOS) version of their Teams app.

Expand to know more

Apps mustn't ask users to make payments within the Teams interface and transmit financial information to users through a bot interface. [Mandatory Fix]

You may provide link to secure external payment services only if you disclose it in your terms of use, privacy policy, profile page, or website before the user agrees to use the app. [Mandatory Fix]

Don't facilitate payments through an app for goods or services prohibited by General policy number 100.10 Inappropriate content. [Mandatory Fix]

Apps running on the iOS or Android version of Teams must adhere to the following guidelines:

• Apps mustn't include in-app purchases, trial offers, or UI that aims to upsell users to paid versions or online stores to purchase other content, apps, or add-ins. [Mandatory Fix]

  

  

• If your app requires an account, users can sign up for an account at no charge. The use of the term free or free account is prohibited. [Mandatory Fix]

• You can determine whether an account is active indefinitely or for a limited time. When the account expires the app mustn't show UI, text, or links indicating the need to pay. [Mandatory Fix]

• Your app's privacy policy and terms of use must be free of any commerce-related UI or links. [Mandatory Fix]

Bots

[Mandatory Fix]

This section is in line with Microsoft commercial marketplace policy number 1140.3.2.

Expand to know more

For apps that use the Microsoft Azure Bot Service (such as bots and message extensions), you must follow all requirements defined in the Microsoft Online Services Terms.

Bots must always ask permission to upload a file and display a confirmation message.

External domains

[Mandatory Fix]

This section is in line with Microsoft commercial marketplace policy number 1140.3.3 and provides developer guidance on usage of restricted domains in the validDomains app manifest property.

Expand to know more

Don't include domains outside of your organization's control (including wildcards) and tunneling services in your app's domain configurations. The following exceptions include:

• If your app relies on SharePoint, you can include the associated root SharePoint site as a valid domain using the {teamSiteDomain} context property. [Mandatory Fix]

• Don't use top level domains such as .com, .in, and .org as a valid domain. [Mandatory Fix]

• Don't use .onmicrosoft.com or as a valid domain where onmicrosoft isn't under your control. However, you can use yoursite.com as a valid domain where yoursite is under your control even though the domain includes a wildcard. [Mandatory Fix]

• If your app is a PowerApp built on the Microsoft Power Platform, you must include apps.powerapps.com as a valid domain to enable your app to be accessible and functional within Teams.

• External domains declared for your submission must not contain URLs. For example, www or https. [Mandatory Fix]

• If your app uses the Azure Bot Service's OAuthCard, you must include token.botframework.com as a valid domain or else the Sign in button won't work. You mustn't declare .botframework.com as wildcards aren't allowed with this domain name. [Mandatory Fix]

• OpenAPI URLs must be under partner control.

• Following External Domains aren't allowed: [Mandatory Fix]

  • *.azurewebsites.net
  • *.azureedge.com
  • *.microsoft.com
  • *.microsoftonline.com
  • *.onmicrosoft.com
  • go.microsoft.com
  • teams.microsoft.com

When using wildcards (*), the following rules apply:

• If a subdomain segment includes a wildcard, it must be the only character in the segment.
• Any segment preceding a wildcard segment must also be a wildcard segment.

For example, *.*.domain.com is valid, but foo.*.myteam.domain.com isn't valid.

Sensitive content

[Mandatory Fix]

Your app mustn't post sensitive data, such as credit card, financial payment details, health, contact tracing, or other personally identifiable information (PII) to an audience not intended to view the content.

App must warn users before downloading any files or executables (.exe) into the user's machine or environment.

General functionality and performance

This section is in line with Microsoft commercial marketplace policy number 1140.4.

• Way forward guidance is mandatory for both admin and existing users. You can add way forward guidance as hyperlinks to sign up, get started, contact us, help links, or email.
• Calling out account dependency or limitations under app functionality isn't required but is mandatory to add it in both app manifest long description and AppSource app listing.
• You must call out any dependency on tenant admins for new users. If there's no dependency, it's mandatory to provide a sign up, contact us, get started link, or email.

Back to top

Launching external functionality

[Mandatory Fix]

Apps mustn't take users out of Teams for core user scenarios. App content and interactions must occur within Teams capabilities, such as bots, Adaptive Cards, tabs, and dialogs (referred as task modules in TeamsJS v1.x).

Note

To redirect users from your Teams app to its native experience through a deep link with a protocol such as tel:, mailto:, or webex:, launch the deep link in a new window by calling the window.open method or using an anchor tag with target="_blank".

Expand to know more

• Link users within Teams app and not to an external site or app. For scenarios that require external functionality, your app must take explicit user permission to launch the functionality. [Mandatory Fix]

• Button UI text that launches external functionality must include content to indicate the user is taken out of the Teams instance. For example, include text such as This way to Contoso.com or View in Contoso.com. [Mandatory Fix]

• Add Pop-out icon to let the users know that they're being navigated outside Teams. You can use the pop-out icon to the right of the link. [Mandatory Fix]

• If you're unable to add a Pop-out icon, you can implement any of the following options to let the user know that they're being navigated outside Teams: [Mandatory Fix]

  • Add a note in Adaptive Card that states that when users select Get Help using this app, it takes the user outside Teams.
  • Add interstitials dialogs.

Compatibility

[Mandatory Fix]

Apps must be fully functional on the latest versions of the following operating systems and browsers:

• Microsoft Windows
• macOS
• Microsoft Edge
• Google Chrome
• iOS
• Android

Your app must show a graceful failure message on unsupported browsers and operating systems.

Response time

[Mandatory Fix]

Teams apps must respond within a reasonable time-frame or show a loading or typing indicator or message or warning.

• Tabs must respond within two seconds or display a loading message or warning. [Mandatory Fix]
• Bots must respond to user commands within two seconds or display a typing indicator. [Mandatory Fix]
• Message extensions must respond to user commands within two seconds. [Mandatory Fix]
• Notifications must display within two seconds of the user action. [Mandatory Fix]

Apps powered by Artificial Intelligence

Explore resources designed to help you with responsible Artificial Intelligence (AI) practices at every stage of innovation such as Microsoft RAI Toolkit and HAX Toolkit Project.

This section is in line with Microsoft commercial marketplace policy for Apps with AI generated content and Microsoft commercial marketplace policy for Apps using facial recognition capabilities.

Apps with AI-generated content

• App must not generate, contain, or provide access to inappropriate, harmful, or offensive AI generated content consistent with existing commercial marketplace policies outlined in 100.10. [Mandatory Fix]

  • Consider using any of the following:
    • Use Teams AI library, Teams-centric interface to GPT-based common language models and user intent engines. [Suggested Fix]
    • Use of moderation hooks, which can be used to regulate bot responses through moderation API. [Suggested Fix]
    • Add conversation sweeping capability, which helps you monitor conversations and intervene when conversations go astray. [Suggested Fix]

• App must provide mechanisms for app users to report inappropriate, harmful, or offensive content to the developer by any of the following mechanisms: [Mandatory Fix]

  • App description including mail ID or link to the portal to log the issue.
  • In app mechanism to log issue along with specific reference to the inappropriate content.

• You must take timely action on reported concerns. [Mandatory Fix]

• App must clearly describe AI functionality before the customer acquires the offer consistent with policy 100.1.3 and prompt user to review the info as a part of in-app functionality. [Mandatory Fix].

  

Apps using facial recognition capabilities

Note

Apps in this category may undergo additional review for adherence to Microsoft’s Responsible AI principles.

• App must not allow use of facial recognition capabilities to identify an individual to be used by or for a police department in the United States. [Mandatory Fix]
• For apps utilizing facial recognition or emotional inference technologies, you must provide a prominent tag or indication of each of these capabilities in the app description. [Mandatory Fix]
  • Apps that use facial expressions or facial movements to infer emotional states, such as anger, disgust, happiness, sadness, surprise, fear, or other terms commonly used to describe the emotional state of a person can be restricted based on the review.
  • Use of facial expressions and movements to detect and classify only individual facial elements, such as smiles or raised eyebrows is permitted. The key distinction is between the detection of facial expressions or movements as visual signals versus the inference of an emotional state.

App package and Teams Store listing

[Mandatory Fix]

App packages must be correctly formatted and include all required information and components.

Tip

• You must ensure the provided test accounts or test environment is valid in perpetuity, that is till the app is live on the commercial marketplace.

• You must include the following detailed testing instructions for validating your app submission:

  • Steps to configure the app test accounts in case app depends on external accounts for authentication.
  • Summary of expected app behavior for the core workflows within Teams.
  • Clearly describe limitations, conditions, or exceptions to the functionality, features, and deliverables in the app long description and related materials.
  • Emphasis on any considerations for testers while validating your app submission.
  • Prepopulate the test accounts with dummy data to aid testing.
  • If you are providing your test accounts, ensure that you enable third-party integration. Also, disable two-factor or multi-factor authentication.

Back to top

App manifest

[Mandatory Fix]

The app manifest defines your app's configuration.

• Your app manifest must conform to a publicly released app manifest schema. For more information, see app manifest reference. Don't submit your app using a preview version of the app manifest.
• If your app includes a bot or message extension, details in the app manifest must be consistent with Bot Framework metadata including bot name, logo, privacy policy link, and terms of service link.
• If your app uses Microsoft Entra ID for authentication, include the Microsoft Entra Application (client) ID in the app manifest. For more information, see the app manifest reference.

Uses of latest app manifest schema

• If your app uses Single sign-on (SSO), you must declare Microsoft Entra ID in the app manifest for user authentication. [Mandatory Fix]

• You must use a publicly released app manifest schema. You can update your app package to use a public version of app manifest schema 1.10 or later. [Mandatory Fix]

• When you submit an app update, only increase the app version number. App ID of the updated app must match the App ID of the published app. [Mandatory Fix]

• The presence of additional files within the app package isn't acceptable. [Mandatory Fix]

• The version number must be the same in the app manifest file schema and additional languages app manifest schema. [Mandatory Fix]

• You must use the app manifest schema version 1.5 or later to localize your app. To use the app schema version 1.5 or later in your manifest.json file, update the $schema attribute to 1.5 or later. Update the manifestVersion property to $schema version (1.5 in this case). [Mandatory Fix]

• When you add, update, or remove an existing capability, add or remove app manifest or Partner Center metadata, you must increase the app version number and submit the new app manifest in your Partner Center account for validation. [Mandatory Fix]

• The version string must follow the Semantic Versioning Specification (SemVer) standard (MAJOR.MINOR.PATCH). [Mandatory Fix]

• If your app requires admins to review permissions and grant consent in Teams admin center, you must declare webapplicationinfo in the app manifest. If webapplicationinfo isn't declared in the app manifest, the Permissions page for your app in Teams admin center is shown as ... [Mandatory Fix]

• As part of Teams app certification, you must submit a production version of the app manifest. [Mandatory Fix]

• We recommend that you declare the Microsoft Partner Network (MPN) ID in the app manifest. The MPN ID helps identify the partner organization that builds the app. [Suggested Fix]

• Scopes and/or context declared in app manifest must be visible within the app. [Mandatory Fix]

App icons

[Mandatory Fix]

Icons are one of the main elements people see when browsing the Teams Store.

Expand to know more

Your icons must communicate your app's brand and purpose while adhering to the following requirements:

• App's color and outline icon submitted in the app listing must match. [Mandatory Fix]

  

  

• Your app package must include two .png versions of your app icon: A color icon and an outline icon. [Mandatory Fix]

• The marketplace icon uploaded as part of the app's marketplace listing in your Partner Center account must match the color icon provided in your app package. [Mandatory Fix]

• The color version of your icon must be 192x192 pixels. Your icon symbol can be any color or colors, but it must sit on a solid or fully transparent square background. [Mandatory Fix]

• The outline version of your icon is displayed in the following scenarios:

  • When your app is in use and hosted on the app bar on the left side of Teams.
  • When a user pins your app's message extension.

• The outline must be 32x32 pixels and can be white with a transparent background or transparent with a white background. The icon mustn't have any extra padding around the symbol. [Mandatory Fix]

• Your app package must include correctly sized and formatted icons. The icons must match the information in Teams Store listing metadata. [Mandatory Fix]

For more information, see icon guidelines.

App descriptions

You must have a short and long description for your app. App description helps improve your app discoverability in the Teams Store. The descriptions in your app configuration and Partner Center must be the same.

Expand to know more

Descriptions mustn't directly or through suggestion derogate another brand (Microsoft owned or otherwise). Ensure that your description doesn’t include claims that can’t be substantiated. For example, Guaranteed 200 percent increase in efficiency.

• App description mustn't contain comparative marketing information. For example, don't use competitor logos or trademarks in the offer listing including tags or other metadata that references competing offers or marketplaces. [Mandatory Fix]

  

• Hyperlink contact details, get started, help, or sign up in app description. [Suggested Fix]

  

  

• App description must identify the intended audience, briefly and clearly explain its unique and distinct value, identify supported Microsoft products and other software, and include any prerequisites or requirements for its use. You must clearly describe any limitations, conditions, or exceptions to the functionality, features, and deliverables as described in the listing and related materials before the customer acquires your offer. The capabilities you declare must relate to the core functions and description of your offer. [Mandatory Fix]

• If you update your app name, replace the old app name with new app name in the offer metadata in the app manifest, AppSource, and wherever applicable. [Mandatory Fix]

• Limitations and account dependencies must be called out in the manifest App Description, AppSource, and Partner Center. For example:

  • Enterprise account
  • Paid subscription
  • Another license or account
  • Language
  • Public switched telephone network (PSTN) dialing
  • Regional dependency
  • Lead time for booking translators or live agents
  • Role based functionality
  • Dependency on native app

  

  

• If your app is supported for specific regions or geographical locations, you must call out that specific region dependency in the app description in app manifest, Partner Center, and AppSource for that offer.

• If you need to reference Teams, write the first reference in the app listing as Microsoft Teams. Later references can be shortened to Teams. [Mandatory Fix]

  

  

Short description

A short description must be a concise summary of your app that highlights its value proposition and is directed at your target audience.

Dos:

• Keep the short description to one sentence.
• Put the most important information first.
• Include keywords that customers are likely to search for.
• Make efficient use of the available character limit. For example, don't repeat your app name.

Don't:

[Suggested Fix]

Use the word app in the short description.

Long description

The long description must provide an engaging narrative that highlights your app's value proposition, primary audience, and target industry. While the description can be as long as 4,000 characters, we recommended you to have a concise description of around 1000 characters.

Dos:

• Use Markdown to format your description.

• Use active voice and speak to users directly. For example, You can ....

• List the key benefits to highlight the advantages of using your app. Add up to three benefits.

• Add the key value proposition of your app in Teams.

• List features with bullet points so it's easier to scan the description.

• Clearly describe limitations, features, conditions or exceptions to the functionality, and deliverables in the listing and related materials before the user installs your app. The Teams capabilities must relate to the core functions described in the listing.

• Ensure that the app description matches with the functionality available inside Teams app. Any reference to workflows outside the Teams app must be limited and distinctly called out from the Teams app functionality.

• Include a help or support link.

• Refer to Microsoft 365 instead of Office 365.

• Use the following language when describing how the app works with Teams (or Microsoft 365):

  • ... works with Microsoft Teams.
  • ... working with Microsoft Teams.
  • ... within Microsoft Teams.
  • ... for Microsoft Teams.
  • ... integrated with Microsoft Teams.
  • ... built for...
  • ... developed for...
  • .. designed for...

Don'ts:

[Mandatory Fix]

• Exceed 500 words.

• Abbreviate Microsoft as MS or MSFT.

  

  

• Indicate the app is an offering from Microsoft, including using Microsoft slogans or taglines.

  

  

• Use the following language unless you're a certified Microsoft partner:

  • ... certified for ...
  • ... powered by ...

• Include typos, grammatical errors.

• Unnecessarily capitalize the entire app manifest or AppSource long description or app content.

  

  

• Include links to AppSource.

  

• Make unverified claims. For example, best, top, and ranked, unless it comes with the source of the claim.

• Compare your offer with other marketplace offers.

For guidance on how to create an accurate, concise, and informative short and long description, see checklist to write app descriptions.

Screenshots

Screenshots provide a prominent visual preview of your app to complement your app name, icon, and descriptions.

Expand to know more

Remember the following:

• You can have up to five screenshots per listing.
• Supported file types include PNG, JPEG, and GIF.
• Dimensions must be 1366x768 pixels.
• Maximum size of 1,024 KB.

Dos:

• Focus on your app's capabilities. For example, how people can communicate with your bot.

• Include content that accurately represents your app.

• Use text judiciously.

• Frame screenshots with a color that reflects your brand and include marketing content.

• Use high-resolution screenshots that are sharp and contain legible and clearly readable text. [Mandatory Fix]

• At least one screenshot must depict your app’s functionality on mobile devices. [Mandatory Fix]

  

• You can have up to five screenshots per listing. You must have a minimum of three and maximum five screenshots in your app listing. [Mandatory Fix]

• Use mockups that accurately depict the app’s actual UI for the benefit of end-users. Screenshots must accurately depict the app’s actual UI or scenarios relevant to and related to the app. [Mandatory Fix]

  

  

• Must depict app functionality or integration with Teams. [Mandatory Fix]

  

• Provided screenshots mustn't incorrectly reference Microsoft Teams as MS, MSFT, or MS Teams. [Mandatory Fix]

• If your Teams app is extensible across Microsoft 365 clients (Microsoft 365, Outlook, and Microsoft Teams), the screenshots provided must depict the app functionality in other Microsoft 365 clients. [Mandatory Fix]

  

• You must provide captions in your screenshots to let the user clearly understand the app capability. [Mandatory Fix]

  

• If your app supports Tabs as a capability, the screenshots showcasing the app in the context of a Teams tab, in app listing, must contain Team’s chrome. [Mandatory Fix]

  

Don'ts:

• Include mockups that inaccurately reflect your app's actual UI, such as showing your app being used outside Teams.

  

Videos

A video in your app listing is one of the most effective ways to communicate why people must use your app. You can add your YouTube or Vimeo video URL that provides the value of your app. Also, as a best practice, we recommended that you add a video that provides the demo or scenario walkthrough of your app. [Suggested fix]

If you choose to submit a video as part of your app listing in your Partner Center account, ensure that you meet the following criteria:

• The video must be short, clear, engaging, and of good quality.

• The video must demonstrate how to set up and use the app.

• The video must be in a narrative form.

• The duration of the video must be within 60-90 seconds for a value video and the recommended duration for a walkthrough video is 3-5 minutes. [Suggested Fix]

• You must turn off advertisements from your YouTube or Vimeo account settings before submitting the video link in the app listing. [Mandatory Fix]

• The video must highlight your app’s functionalities and integration within Teams. [Mandatory Fix]

• The video must be available as a functional link. [Mandatory Fix]

• The video must be in the format https://www.example.com/123456789.

  

• The video can be surfaced in the first position of the screenshots or videos carousel in the app details (Teams Store and Admin Center) and AppSource pages. [Suggested Fix]

• The video on demo or scenario walkthrough must intend to educate users and not to promote your app.

For more information on the criteria for creating an app value video or walkthrough video, see the checklist to create a video.

Privacy policy

[Mandatory Fix]

The privacy policy can be specific to your Teams app or an overall policy for all your services.

• If you use a generic privacy policy template, you must add a reference to services, applications, or platforms in the scope of your privacy policy. You don’t need to specify your Teams app in the scope, if you include a reference to services, applications, and platforms. The app validation process interprets these references to include your Teams app along with your other services or websites.
• Must include how you handle user data storage, retention, and deletion. You must describe the security controls for data protection.
• Must include your contact information.
• Must not include URLs that are broken or for beta or staging purposes.
• Must not include links to AppSource.
• Must not require authentication to access privacy policy.
• Must not include any commerce UI or store links.
• Must have the same link in the app manifest and AppSource.

Terms of use

[Mandatory Fix]

Use the following guidelines to write the Terms of use:

• Must be specific and applicable to your offering.
• Must be hosted on your own domain.
• Must have a secure (HTTPS) link.
• Access to Terms of use must not require authentication.
• Must have the same link in the app manifest and AppSource.

Support links

[Mandatory Fix]

Your app's support URLs mustn't require authentication. For example, users must be allowed to contact you without sign in.

Expand to know more

Support URLs must include your contact details or a way forward for users to raise a support ticket. For example, if your support URL is hosted on GitHub, the GitHub page must be under your ownership and must include your contact details or a way forward for users to raise a support ticket.

Localization

[Mandatory Fix]

• If your app supports localization, your app package must include a file with language translations that display based on the Teams language setting. The file must conform to the Teams localization schema. For more information, see Teams localization schema. [Mandatory Fix]

• App metadata content must be the same in en-us and other localization languages. [Mandatory Fix]

• Supported languages must be displayed in the AppSource app description. For example, this app is available in X (X= localized language). [Mandatory Fix]

• If the user's client settings don't match with any of your additional languages, the default language is used as the final fallback language. Update the localizationInfo property with the correct default language that your application supports. [Mandatory Fix]

• Update the localizationInfo property with the correct default language your application supports or add localized content for app manifest and Partner Center long and short description. [Mandatory Fix]

Apps linked to SaaS offer

This section is in line with Microsoft commercial marketplace policy number 1140.5. If you're building a Teams app linked to a Software as a Service (SaaS) offer, ensure that it adheres to these guidelines.

General

• ISVs must support the ability for multiple users (Subscribers) in the same tenant to manage their own subscription and assign licenses to users in the tenant.
• The offer must meet all the technical requirements for Teams apps linked to a SaaS offer.
• The Teams apps linked to SaaS offer must meet all the requirements defined in 1000 Software as a Service (SaaS).
• subscriptionOffer details mentioned in the app manifest file must be correct. In your app manifest, add or update node subscriptionOffer with value publisherId.offerId. For example, if your publisher ID is contoso1234 and your offer ID is offer01, the value that you specify in your app manifest must be contoso1234.offer01.
• Linked SaaS offer to the Teams app must be live in AppSource and preview offers aren't accepted for Teams Store approval.

Offer metadata

• Offer metadata must match across the app manifest, the Teams app listing in AppSource, and the SaaS offer in AppSource.
• Teams app and SaaS offer must be from the same publisher or developer. The SaaS offer referenced in the app manifest must belong to the same publisher as the Teams app is submitted to the commercial marketplace.
• As your submitted offer is a Teams app linked to SaaS offer, you must select Additional purchases as Yes, my product requires purchase of a service or offers additional in-app purchases​ in Partner Center product set-up section of your offer listing.
• Plan descriptions and pricing details must provide enough information for users to clearly understand the offer listings.
• Any limitations, dependencies on additional services, and exceptions to features offered must be accurately called out in plan descriptions.
• The Teams apps linked to SaaS offer are designed to support licenses assigned on a named, per-user basis. Sometimes, the SaaS offer is built with other method or has specialized purchase flows. You must clearly mention in the app metadata and subscription plan details about the method and purchase flows.
• SaaS offer must provide messages and guidance to all users in all applicable states of purchase flow.

SaaS offer home page and license management

• Provide introduction to subscribers on how to use the product.

• Allow the subscriber to assign licenses.

• Provide different ways to engage with support for issues, such as FAQ, knowledge base, and email.

• Validate users to ensure that they don’t already have license assigned through another user.

• Notify users after license assignment.

• Guide users on how to add the app to Teams and get started through Teams chat bot or email.

• If a SaaS app uses Microsoft license management, after the confirmation of the app subscription on the ISV's landing page, the user must be redirected to the Microsoft license management in Teams to avoid a dead-end and allow the user to manage licenses within Teams.

Usability and functionality

• After successful purchase and assignment of licenses, you must provide the following:
  • Access to users for subscribed plan features.
  • Value addition and significant benefits of subscription plan to users.
  • From your Teams app, provide link to the SaaS application home page for subscribers to manage the licenses in the future.

Configure and test SaaS application

If setup of your app for testing purposes is complex, provide an end-to-end functional document, linked SaaS offer configuration steps, and instructions for license and user management as part of your Notes for Certification.

Tip

You can add a video on how your app and license management works to assist the team for testing.

Back to top

Tabs

This section is in line with Microsoft commercial marketplace policy number 1140.4.2. If your app includes a tab, ensure that it adheres to these guidelines.

Tip

For more information on creating a high-quality app experience, see Teams tab design guidelines.

Setup

• Tab setup mustn't dead-end a new user. Provide a message on how to complete the action or workflow. [Mandatory Fix]

  

• The user mustn't leave the tab configuration experience inside Teams to create content outside Teams and then return to Teams to pin it. Tab configuration screen must explain the value of configuration and how to configure. [Mandatory Fix]

  

• Tab configuration screen mustn't embed an entire website. Keep your configuration experience focused. For example, if you're building a project management app that lets users configure a project in a channel, keep the tab configuration screen focused on allowing the user to select a project from your app to configure in the channel. [Mandatory Fix]

  

  

• Apps that require users to input a URL while configuring a tab must:

  • Provide an appropriate way forward guidance for the user to acquire or generate the URL. [Mandatory Fix]

  • Check for URL that is relevant or appropriate to the app’s functionality as per the app description. [Mandatory Fix]

    

    

• Hyperlink the contact us information in the configuration screen instead of plain text to help users to contact you for support requirements. [Mandatory Fix]

• For a seamless first run user experience, we recommend that you hyperlink your support URL or email in the configuration screen. [Suggested Fix]

Views

• The sign in screen area mustn't use large logos. [Mandatory Fix]

  

• Content can be simplified by breaking down across multiple tabs.

  

• Tabs shouldn't have a duplicate header. Remove duplicate logos from the I-frame since the tab framework already displays the app icon and name. [Suggested Fix]

  

  

Navigation

The following are the navigation guidelines:

• Tabs mustn't provide navigation that conflicts with the primary Teams navigation. If you provide a left navigation in your tab, it mustn't include only icons or icons with stacked text. It mustn't be a collapsible rail with the option to see icons with stacked text (mimicking the Teams navigation bar). Include icons with in line text or only text or use hamburger menus instead of tab left rail. [Mandatory Fix]

  Design your app with basic and advanced Fluent UI components.

  

  

• If your tab has a toolbar on the left rail without any navigation component, the toolbar must leave 20 pixels spacing from Teams left navigation. [Mandatory Fix]

  

• The secondary and tertiary pages in a tab must be opened in a level two (L2) and level three (L3) view in the main tab area, which is navigated via breadcrumbs or left navigation. You can also use the following components to aid navigation in a tab:

  • Back buttons

  • Page headers

  • Hamburger menus

    

• Deep links in tabs mustn't link to an external webpage but within Teams. For example, dialogs or other tabs. [Mandatory Fix]

  

• Tabs mustn't allow users to navigate outside Teams for the core app experience. Tabs can redirect outside Teams for non-core workflows. For example, to raise a support ticket. [Mandatory Fix]

  

  

• Horizontal scroll mustn't be present in an in-meeting tab. [Mandatory Fix]

• In-meeting dialogs used in your app mustn't allow horizontal scrolling. Use in-meeting dialogs sparingly and for scenarios that are light and task oriented. You can specify the width of the in-meeting dialog’s I-frame within the supported size range to account for different scenarios. [Mandatory Fix]

• Dialogs used in your app mustn't allow horizontal scrolling. Dialogs allow you to select different sizes to make the content responsive without the need of Horizontal scroll. If necessary, you can use a Stageview (a full screen UI component to surface your web content) to complete the workflow without Horizontal scroll. [Mandatory Fix]

• Horizontal scroll present in the tab in a personal chat, channel, and in-meeting details tab in any scope isn't allowed if the entire tab canvas is scrollable, unless your tab uses an infinite canvas with fixed UI elements. [Mandatory Fix]

  

  

  

  

  

• The user must have an option to go to previous work state. [Mandatory Fix]

  

  

• Horizontal scroll in Adaptive Cards mustn't be present in Teams. [Mandatory Fix]

• Bottom rail used for navigation in tabs mustn't conflict with Teams native mobile app navigation. [Mandatory Fix]

  

Usability

• Content mustn't truncate or overlap within the tab. [Mandatory Fix]

  

• Users must be able to undo their last action in the tab. [Mandatory Fix]

• Tabs in a personal context may aggregate content from shared instances of the app. For example, a project management app with a configurable tab that lets channel members comment on the project on Kanban cards, must aggregate this content and display in the personal app. [Suggested Fix]

• Tabs must be responsive to Teams themes. When a user changes the theme, the app's theme must reflect the selection. [Suggested Fix]

  

  

• Tabs must use Teams styled components such as, Teams fonts, type ramps, color palettes, grid system, motion, tone of voice, whenever possible. For more information, see tab design guidelines. [Suggested Fix]

  

• If your app functionality requires changes in settings, include a Settings tab. [Suggested Fix]

• Tabs must follow Teams interaction design such as, in-page navigation, position and use of dialogs, information hierarchies. For more information, see Microsoft Teams Fluent UI kit. [Suggested Fix]

• Tab experiences must be fully responsive on mobile (Android and iOS). [Mandatory Fix]

  Tip

  • Include a personal bot alongside a personal tab.
  • Allow users to share content from their personal tab.

• Tab mustn't contain elements that completely obstruct or impede workflows within the tab. For example, bot inside a tab that can't be minimized. [Mandatory Fix]

  

• Tab mustn't have a broken functionality. Your offer must be a usable software solution and must provide the functionality, features, and deliverables as described in your listing and other related materials. [Mandatory Fix]

• If your tabs contain a footer, ensure that you remove all links unrelated to app functionality from the footer. [Mandatory Fix]

Scope selection

• Content in the landing page of configurable tabs mustn't be scoped for individual use and not include personal content such as My Tasks or My Dashboard. [Mandatory Fix]

  

• After the configuration experience, the landing page must show a collaborative view for the entire team. [Mandatory Fix]

• If your app requires provision of a personal scope view for the user to enhance efficiency or workplace productivity, use filtered views, deep links to personal apps, or navigate to L2 or L3 views within the configurable tab and keep the landing page contextually the same for all the users. [Mandatory Fix]

• Content in the landing page of the configurable tabs must be contextually same for all members of the channel. [Mandatory Fix]

  

• Configurable tabs must have focused functionality. [Mandatory Fix]

  

Back to top

Bots

This section is in line with Microsoft commercial marketplace policy number 1140.4.3.

If your app includes a bot, ensure that it adheres to these guidelines.

Tip

For more information on creating a high-quality app experience, see Teams bot design guidelines.

Bot design guidelines

• Your Teams app must follow Teams bot design guidelines.

• You must implement a dialog to avoid multi-turn bot response when the workflow involves the user performing repetitive tasks. For example, use a dialog to repetitively capture name, dob, place, and designation instead of using multi-turn conversations. [Mandatory Fix]

• Any broken links, responses, or workflows in your app must be fixed. [Mandatory Fix]

Bot commands

Analyzing user input and predicting user intent is difficult. Bot commands provide users a set of words or phrases for your bot to understand.

• All commands that your bot supports must work correctly, including generic commands such as Hi, Hello, and Help. [Mandatory Fix]

  

  

• Bot commands mustn't lead a user to a dead end, the commands must always provide a way forward. [Mandatory Fix]

  

• You must list at least one valid bot command in the items.commands.title section of the app manifest and add a suitable description that gives clarity to the user on the bot command and its usage. Bot commands listed in the commandLists section of the app manifest surface as prepopulated commands in the bot command menu and provide a way forward for the new user to interact with the bot. [Suggested Fix]

• Bot response mustn't contain any official Microsoft product images or avatars. Use your own assets in your app. Use of Microsoft product images in your app isn't allowed. You may only copy, modify, distribute, display, license, or sell Microsoft copyrighted product images if you're granted explicit permission within the End-User License Agreement (EULA), license terms that accompany the content, or in the Microsoft Trademark and Brand guidelines. [Mandatory Fix]

• Bots must respond to user commands without displaying a continuous loading indicator. [Mandatory Fix]

• Bot help command response mustn't redirect the user outside Teams. Bot help command response can redirect user to a canvas within the Teams app or provide a way forward response in an Adaptive Card. [Mandatory Fix]

  

• Bots must always provide a valid response to a user input even if the input is irrelevant or improper. [Mandatory Fix]

  

  

• Special characters such as slash (/), mustn't be prefixed to bot commands. [Mandatory Fix]

  

• Bots must provide a valid response to invalid user commands. Bots mustn't dead-end the user or display an error if a user sends an invalid bot command. [Mandatory Fix]

  

  

• Bot functionality must be relevant to the scope in which the bot is installed and the bot must provide value in the installed scope. [Mandatory Fix]

• Bots mustn't contain duplicate commands. [Mandatory Fix]

• Bots mustn't display a typing indicator after responding to the user command, but can display a typing indicator while responding to the user command. [Mandatory Fix]

• Bots must provide a valid response to the help command typed in lowercase or uppercase that provides the user with a way forward or lets the user access the help content related to the bot usage. Bots must provide a valid response even when the user hasn't logged on to the app. [Mandatory Fix]

  

  

• Bots must provide a valid response to help command.

  

• Bot responses on mobile must be responsive without any data truncation that hampers the end-user's bot usage to complete desired workflows. [Mandatory Fix]

  

  

• All the links in a bot response adaptive card must be responsive. Any link that takes the user outside the Teams platform must have a clear redirect text such as, View in.. or This way to.., a pop-out icon in the bot response action button, or have a suitable redirect text in the bot response message body. [Mandatory Fix]

  

• By design, if your bot doesn't respond or support any user command and is a one way bot only intended to notify users. You must set isNotificationOnly to true in the app manifest. [Mandatory Fix]

  

  

• Bot user experience mustn't be broken on mobile platforms. Your bot must be fully responsive on mobile. [Mandatory Fix]

Tip

For personal bots, include a Help tab that further describes what your bot can do.

Bot welcome messages

• If the app has a complex configuration flow (requires an enterprise license or lacks an intuitive sign up flow), then bots in such apps must always send a welcome message during the first run.

  For best experience, the welcome message must include the value offered by the bot to users, who installed the bot in channel, how to configure the bot, and briefly describe all supported bot commands. You can display the welcome message using an Adaptive Card with buttons for better usability. For more information, see how to trigger a bot welcome message. For apps without a complex configuration flow, you can choose to trigger a welcome message during the bot first run experience. However, if a welcome message is triggered, it must follow the welcome message guidelines.

  

  

• Bot welcome messages in channels and chats are optional during first run, especially if the bot is available for personal use and performs similar actions. Your bot mustn't send welcome messages to users individually (it's considered spamming). The message must also mention the person who added the bot.

  

  

• Notification only bots must send a welcome message that clarifies that the bot is a notification only bot and users won't be able to interact with the bot. [Mandatory Fix]

  

• Welcome message mustn't dead-end the user. Welcome message must include the value offered by the bot to the users who installed the bot in channel, how to configure the bot, and briefly describe all supported bot commands. You can display the welcome message using an Adaptive Card with buttons for better usability. [Mandatory Fix]

  

  

• Bot installed in a channel or group chat scope mustn't send proactive welcome message to all the team members in 1:1 chat. [Mandatory Fix]

  

• Notification only bot can send a proactive welcome message in a channel only if the message contains important information for any user to complete the configuration for the bot or clarifies the scenarios when notifications are triggered. [Mandatory Fix]

• Bot installed in a channel or group chat scope mustn't send proactive messages (not just welcome message) that are irrelevant to all users in channel or group chat, instead must send proactive messages to the user over 1:1 chat. [Mandatory Fix]

• Bot installed in a channel or group chat scope mustn't allow users to start individual workflows. Bots must complete individual workflows in 1:1 chat with the user. [Mandatory Fix]

• Bot welcome message must clearly call out the limitations related to bot usage in the installed scope. [Mandatory Fix]

  

  

• Welcome message must auto trigger on app install in a personal scope. If the bot doesn't send a welcome message in a personal scope, the user is lead to a dead-end. If the app doesn't include a complex configuration workflow, it's optional for the developer to trigger a welcome message in the channel or group chat scope. [Mandatory Fix]

  

• Welcome messages must trigger only once on bot install. Welcome messages mustn't trigger every time the user invokes the help command. Help command response must be focused to include a way for the user to access help related to the bot. [Mandatory Fix]

• Welcome messages mustn't trigger with every bot command. This is considered spam. [Mandatory Fix]

  

• Welcome message content must be related to the bot workflow mentioned in the app’s long description and the installation scope. Welcome message must include the value offered by the bot to users who installed the bot in channel, how to configure the bot, and briefly describe all supported bot commands. [Mandatory Fix]

• Bot mustn't send multiple welcome messages when triggered on app install. [Mandatory Fix]

  

• App name in the welcome message must match the app name in the app manifest. [Mandatory Fix]

  

• Welcome message mustn't display competitor chat based collaborative platform names unless the app provides specific interoperability.

• Welcome message mustn't redirect the user to another Teams app, instead the welcome message must nudge the user to complete their first task and briefly describe all supported bot commands in the app. [Mandatory Fix]

• Welcome message mustn't contain links to any app marketplace including AppSource. [Mandatory Fix]

• If your app has a complex configuration workflow that requires admin led installation, doesn't have an intuitive and readily available sign up flow, or requires users to complete configuration steps outside the Teams experience and return then the bot must send a proactive welcome message in a team or group chat scope after installation. [Mandatory Fix]

• If your bot sends a welcome message in the channel, it mustn't send it to users individually (It's considered spamming). The welcome message must also mention the person who added the bot. [Suggested Fix]

Tip

In welcome messages to individual users, a carousel tour can provide an effective overview of your bot and any other app features to encourage users to try bot commands. For example, Create a task.

Bot message spamming

Bots mustn't spam users by sending multiple messages in short duration.

• Bot messages in channels and chats: Don't spam users by creating separate posts. Create a single post with replies in the same thread. [Mandatory Fix]

  

  

• Bot messages in personal apps:

  • Don't send multiple messages in quick succession. [Mandatory Fix]

    

  • Send one message with complete information. [Mandatory Fix]

  • Avoid multi-turn conversations to complete a single repetitive workflow. [Mandatory Fix]

  • Use a form (or dialog) to collect all inputs from a user at one time. [Mandatory Fix]

  • NLP based conversational chatbots can use multi turn conversation to make the discussion more engaging and complete a workflow.

    

    

• Welcome messages: Don't repeat the same welcome message over regular intervals. For example, when a new member is added to a team, don't spam the other members with a welcome message. Message the new member personally. [Mandatory Fix]

  

Bot notifications

Bot notifications must include content relevant for the scope you define for the bot (team, chat, or personal). [Mandatory Fix]

Bots and Adaptive Cards

Adaptive Cards are a highly recommended way to display bot messages. The cards must be lightweight and only include up to six actions. To display more content, consider using a dialog or tab.

For more information about cards, see:

• Designing Adaptive Cards
• Cards reference

Bot experience must be fully responsive on mobile. Bot responses must provide a way forward where applicable. Bot musts be responsive and fail with a graceful error message for failures. Bot messages sent in the personal scope to user's base on triggers in a collaborative scope must provide contextual information (including the message’s origin).

Notification only bots

Apps that consist of notification only bots provide user value by triggering user notifications based on certain triggers or events in the core app or backend. For example, a new sales lead or prospect is added for the sales team to follow up on. A high-quality notification only bot notifies the users regularly on certain event completions such as workflow completions or alerts.

Tip

Preview information and provide basic in line user actions in the posted card so that the user isn't required to navigate outside Teams for all actions (irrespective of complexity).

Bot metadata information

• Bot information in the app manifest (bot name, logo, privacy link, and terms of service link) must be consistent with the Bot Framework metadata. [Mandatory Fix]

• Ensure that the bot ID in the app manifest matches with bot ID in the last Teams Store published version of your app. Changing bot IDs in an app update leads to permanent loss of all user interaction history with the bot for existing users of your app and starts a new conversation chain with the new Bot ID. [Mandatory Fix]

• Any change to app name, metadata, bot welcome message, or bot responses must be updated with new name. [Mandatory Fix]

• App name in the bot welcome message or bot responses must match the app name in the app manifest. [Mandatory Fix]

Bot in collaborative scope

• Bot installation in a channel or group chat scope to obtain the team roster for sending proactive notifications for users as 1:1 chats for team specific triggers isn't allowed. For example, app that pairs people for a meetup. [Mandatory Fix]

• Bot in a channel or a group chat only used to obtain the messages or posts for sending proactive notifications for users as 1:1 chats isn't allowed. [Mandatory Fix]

• Bots installed in collaborative scope must provide a user value in the collaborative scope. [Mandatory Fix]

Back to top

Message extensions

This section is in line with Microsoft commercial marketplace policy number 1140.4.4.

If your app includes a message extension, ensure that it adheres to these guidelines.

Tip

For more information on creating a high-quality app experience, see the Teams message extension design guidelines.

Messaging extensions design guidelines

• If your Teams app uses the messaging extension capability, your app must follow the Messaging extension design guidelines.

  

• Messaging extensions are shortcuts for inserting app content or acting on a message without navigating away from the conversation. Keep your messaging extension simple and display only the components required to effectively complete the action. Complete website mustn't be I-framed within the messaging extension. [Mandatory Fix]

• Preview images in Adaptive Cards in messaging extensions must load properly. [Mandatory Fix]

  

  

• Messaging extension response card must include the app icon to avoid end user confusion. [Mandatory Fix]

• Your app mustn't have any broken functionality. App mustn't dead-end or block the user from completing a workflow in a messaging extension. [Mandatory Fix]

• Messaging extensions must respond or work as intended in group chat and channel scopes. [Mandatory Fix]

• You must include a way for the user to sign in or sign out from the messaging extension. [Mandatory Fix]

• Message extensions that use OpenAPI urls must not provide redirection on any API call. Actual API calls must be served from the same domain or subdomain of the root domain.

Action commands for Action-based message extensions

Action-based message extensions must do the following:

• Allow users to trigger actions on a message without completing intermediate steps, such as sign in.

  

  

• Pass the message context to the next work state. [Mandatory Fix]

  

  

• Incorporate the host app name instead of a generic verb for action commands triggered from a chat message, channel post, or call to action within apps. For example, use Start a Skype Meeting for Start Meeting, Upload file to DocuSign for Upload file. [Suggested Fix]

  

  

• Invoking a message action must allow the user to complete the workflow. Errors, blank responses, or continuous loading indicators to make the message action functional as intended mustn't be present. [Mandatory Fix]

  

• Duplicate action commands mustn't be present. [Mandatory Fix]

• Message actions must allow the user to complete the workflow as intended without an invalid response. [Mandatory Fix]

• Apps with only action-based messaging extension must have the following end state:

  • Post a relevant action as a notification either in the context where message extension is invoked or in 1:1 bot chat based on user scenario. [Mandatory Fix]

  • Allow users to share cards with other users based on the action taken. This is to ensure that apps don't take silent actions. For example, a ticket is created based on a message in a channel, but the app doesn't send a notification or doesn't provide a way to request the user to share ticket details after the ticket is created. [Mandatory Fix]

Preview links (link unfurling)

[Mandatory Fix]

• If the app has declared the supportsAnonymizedPayloads property in the app manifest and the user hasn't installed the app, the app link must unfurl and show the add app dialog after the card is selected. [Mandatory Fix]

• Message extensions must preview recognized links in the Teams compose box. Don't add domains that are outside your control (either absolute URLs or wildcards). For example, yourapp.onmicrosoft.com is valid but *.onmicrosoft.com isn't valid. Top-level domains also are prohibited. For example, *.com or *.org. [Mandatory Fix]

• Apps must only declare that are under the app publisher’s direct ownership in the messageHandler link unfurling section of the app manifest. It mustn’t contain *.botframework.com. [Mandatory Fix]

Search commands

• Search based message extensions must provide text that helps the users to search effectively. [Mandatory Fix]

  

  

• @mention executables must be clear, easy to understand, and readable.

  

Back to top

Dialogs

[Mandatory Fix]

This section is in line with Microsoft commercial marketplace policy number 1140.4.5.

Expand to know more

A dialog (referred as task module in TeamsJS v1.x) must include an icon and the short name of the app it's associated with. Dialogs mustn't embed an entire app and only display the components required to complete a specific action.

For more information, see Teams dialog design guidelines.

Tip

For more information on creating a high-quality app experience, see Teams task module design guidelines.

Back to top

Meeting extensions

This section is in line with Microsoft commercial marketplace policy number 1140.4.6.

Tip

For more information on creating a high-quality app experience, see the Teams meeting extension design guidelines.

Meeting extension design guidelines

• Your Teams apps must follow Meeting extension design guidelines.

• With the in-meeting app experience, you can engage participants during the meeting by using in-meeting tabs, dialog box, and the in-meeting share to stage feature. If your app supports Teams meeting extension, you must provide a responsive in-meeting experience aligned with the Teams meeting experience. [Mandatory Fix]

• Meeting extensibility apps must offer a responsive in-meeting experience aligned to the Teams meeting experience. In-meeting experience is mandatory for a Teams app that supports meeting extensibility but, pre- and post-meeting experiences aren't mandatory. [Mandatory Fix]

  • With the pre-meeting app experience, users can find and add meeting apps. Users can also perform pre-meeting tasks such as developing a poll to survey the meeting participants. If your app provides a pre-meeting experience, it must be relevant to the workflow of the meeting.

  • With the post-meeting app experience, users can view the results of the meeting such as, poll survey results or feedback and other app content. If your app provides a post-meeting experience, it must be relevant to the workflow of the meeting.

  • With the in-meeting app experience, you can engage meeting participants during the meeting and enhance the meeting experience for all the attendees. Attendees mustn't be taken outside the Teams meeting for completing core user workflows of your app.

  

• Your app must offer value beyond providing only custom Together Mode scenes in Teams. [Mandatory Fix]

• You must declare groupChat as a scope under configurableTabs and meetingDetailsTab, meetingChatTab, and meetingSidePanel as a context property in the app manifest to enable your app for meetings on Teams mobile. [Mandatory Fix]

• Meeting canvases mustn't dead-end a meeting attendee. Meeting canvases must show a graceful failure message for app limitations such as, region specific dependency. [Mandatory Fix]

• The meeting canvas’ header must display the correct app name to avoid confusing the meeting attendee. [Mandatory Fix]

• You must include an option for the user to sign out or log out from the meeting extension. [Mandatory Fix]

• Meeting tabs on mobile platforms must include relevant workflows. Blank pages mustn't be present in a meeting tab. [Mandatory Fix]

• Meeting stage is a focused, intuitive, and collaborative participation canvas. Meeting stage mustn't embed the complete website experience. [Mandatory Fix]

• App mustn't show continuous loading screen, error, or broken functionality that dead-ends the user or blocks completion of a workflow in a meeting scenario. [Mandatory Fix]

  

• App mustn't open a new Teams instance on starting a meeting. Meeting canvases are an extension of the Teams capabilities that promote real time collaboration and new meetings must always open within the currently active Teams instance. [Mandatory Fix]

• Meeting apps must complete workflows within the Microsoft Teams platform without redirecting to competitor chat based platforms. [Mandatory Fix]

  

• If your app supports role based views and certain workflows are unavailable to all participants, we recommend that you implement proper messaging for participants in tab and side-panel stating that the app is for organizer's view and provide details about how the attendees receive the meeting notes, action items, and update agendas. [Mandatory Fix]

  

Pre- and post-meeting experience

• Pre and post meeting screens must adhere to general tab design guidelines. For more information, see Teams design guidelines. [Mandatory Fix]

• Tabs must have an organized layout when displaying multiple items. For example, more than 10 polls or surveys, see example layout. [Mandatory Fix]

• Your app must notify users when the results of a survey or poll are exported by stating, Results successfully downloaded. [Mandatory Fix]

  

In-meeting experience

• Apps must only use a dark theme during meetings. For more information, see Teams design guidelines. [Mandatory Fix]

• A tooltip must display the app name when hovering over the app icon during meetings. [Mandatory Fix]

  

• Message extensions must function the same during meetings as they do outside meetings. [Mandatory Fix]

In-meeting tabs

• Must be responsive. [Mandatory Fix]

• Must maintain padding and component sizes. [Mandatory Fix]

• Must have a back button if there's more than one layer of navigation. [Mandatory Fix]

  

  

• Must not include more than one close button. It may confuse users since there's already a built-in header button to dismiss the tab. [Mandatory Fix]

• Must not have Horizontal scroll. [Mandatory Fix]

  

  

In-meeting dialogs

• Must be used sparingly and for scenarios that are light and task oriented. [Mandatory Fix]

• Must display content in a single column and not have multiple navigation levels. [Mandatory Fix]

  

  

• Must not use dialogs. [Mandatory Fix]

• Must align with the center of the meeting stage. [Mandatory Fix]

  

• Must be dismissed after a user selects a button or performs an action. [Mandatory Fix]

• Together mode: Ensure that you consider the following best practices for a scene building experience: [Mandatory Fix]

  • All images are in .png format.
  • The final package with all the images put together mustn't exceed 1920x1080 resolution. The resolution is an even number. This resolution is a requirement for scenes to be shown successfully.
  • The maximum scene size is 10 MB.
  • The maximum size of each image is 5 MB. A scene is a collection of multiple images. The limit is for each individual image.
  • Select Transparent as required. This checkbox is available on the right panel when an image is selected. The overlapping images must be marked as Transparent to indicate that they're overlapping images in the scene.

Shared Meeting Stage

To use the shareAppContentToStage API, you must declare the correct RSC permissions. In the app manifest, you must configure the authorization property. Update the name property as MeetingStage.Write.Chat and type property as Delegated in the resourceSpecific field. [Mandatory Fix]

Shared meeting stage feature can only be launched through the Teams desktop app. However, the shared meeting stage consumption experience must be usable and not broken when viewed on mobile devices. [Mandatory Fix]

Back to top

Connector

1. The connector name must be the same as the app name within the app and in the app manifest.

   

2. The user must not encounter any error while configuring the connector.

   

Notifications

This section is in line with Microsoft commercial marketplace policy number 1140.4.7.

If your app uses the activity feed APIs provided by Microsoft Graph, ensure that it adheres to the following guidelines.

Tip

If your apps supports notification scenarios where the notifications are triggered after long intervals, for example, after one day or one month. Before you submit for review, ensure that you trigger such notifications in the background for us to test the notifications.

Notification design guidelines

• Your Teams apps must follow activity feed notifications design guidelines.

• Irrelevant, improper, unresponsive, or broken workflow mustn't be present after user selects a notification in Teams activity feed. Users mustn't be blocked from completing a workflow after they select an activity feed notification. [Mandatory Fix]

• Include your app’s name in the activity feed notification for end-users to understand the source or trigger for the notification without confusion. [Mandatory Fix]

• App must trigger notifications for all the notification scenarios mentioned in the app long description, app first run experience, and in scenarios declared under activityTypes in the app manifest. [Mandatory Fix]

• Notifications must display within five seconds of user action. [Mandatory Fix]

• You must call out notification limitations (if any) in your app long description or in the app’s first run experience. [Mandatory Fix]

General

• All the notification triggers specified in your app configuration must work. [Mandatory Fix]
• Notifications must be localized per the supported languages configured for your app. [Mandatory Fix]
• Notifications must display within five seconds of user action. [Mandatory Fix]
• Notifications must be localized as per the supported languages for all the platforms where your app is compatible. [Mandatory Fix]

Avatars

• The notification avatar must match your app's color icon. [Mandatory Fix]
• Notifications triggered by a user must include the user's avatar. [Mandatory Fix]

Spamming

• Apps mustn't send more than 10 notifications per minute to a user. [Mandatory Fix]
• Bots and the activity feed mustn't trigger duplicate notifications. [Mandatory Fix]
• Notifications must provide some value to users and not be used for trivial or irrelevant events. [Mandatory Fix]

Navigation and layout

• Notifications must adhere to the Teams activity feed layout and experience. [Mandatory Fix]
• When selecting a notification, the user must be directed to relevant content within Teams. [Mandatory Fix]

Back to top

Microsoft 365 App Compliance Program

This section is in line with Microsoft commercial marketplace policy number 1140.6.

Expand to know more

The Microsoft 365 App Compliance Program is intended to help organizations assess and manage risk by evaluating security and compliance information about your app. If you're publishing an app to the Teams Store, you must complete the following tiers of the program:

• Publisher Verification: Helps admins and end users understand the authenticity of app developers integrating with the Microsoft identity platform. When completed, a blue verified badge displays on the Microsoft Entra consent dialog and other screens. For more information, see Mark your app as publisher verified. [Mandatory Fix]

  

• Publisher Attestation: A process in which you share general, data handling, and security and compliance information to help potential customers make informed decisions about using your app. [Suggested Fix]

For an app that isn't previously listed, you can't complete Publisher Attestation until the app is available in Teams Store. If you're updating an already listed app, complete Publisher Attestation before submitting the latest version of the app.

Back to top

Advertising

This section is in line with Microsoft commercial marketplace policy number 1140.7.

Apps mustn't display advertising, including dynamic ads, banner ads, and ads in message. [Mandatory Fix]

Back to top

Cryptocurrency based apps

You must demonstrate compliance with all laws where your app is distributed, if your app: [Mandatory Fix]

• Facilitates cryptocurrency transactions or transmissions within the app.

• Promotes cryptocurrency related content.

• Enables users to store or access their stored cryptocurrency.

• Encourages or enables users to complete a cryptocurrency based transaction or transmission outside the Teams platform.

• Encourages or facilitates mining of cryptocurrency tokens.

• Facilitates user participation in Initial Coin Offerings.

• Rewards or incentivizes users with cryptocurrency tokens for completing a task.

After an internal Microsoft review, if the compliance demonstration is satisfactory, Microsoft may proceed with further certification of your app. If the compliance demonstration is unsatisfactory, Microsoft keeps you informed of the decision to not proceed with certification of your app.

Back to top

App functionality

• Workflows or content in the app must be related to the scope. [Mandatory Fix]
• All app capabilities must be functional and must work properly as described in the AppSource or app manifest long description. [Mandatory Fix]
• Apps must always notify the user before downloading any file or executable on the user’s environment. Any call to action (CTA), either text based or otherwise, that makes it clear to the user that a file or executable is downloaded on user action is allowed in the app. [Mandatory Fix]
• Apps with region dependency must notify the users with a graceful failure message in all applicable capabilities if they attempt to use it in an unsupported region. [Mandatory Fix]

Back to top

Mobile experience

• Mobile add-ins must be free. There mustn't be any in-app content or links that promote upselling, online stores, or other requests for payment. Any accounts required for apps must have no charge for use and if time-limited, mustn't include any content indicating a need to pay. [Mandatory Fix]

  

• Use of the word FREE, FREE TRIAL, or TRY FREE is allowed on desktop or web app experience without any limitation or consideration.

• Use of the word FREE as plain text in the context of a trial or app upgrade is allowed on mobile.

• Use of the word FREE in the context of a trial or app upgrade with a link that leads to a landing page without payment or pricing information is allowed on mobile. Plain text to signal app is PAID is allowed on mobile.

• Use of the word FREE as plain text in the context of a trial or app upgrade and associated with pricing details isn't allowed on mobile. [Mandatory Fix]

• Use of the word FREE in the context of a trial or app upgrade and associated with a link that leads to a landing page with pricing information or payment details on mobile isn't allowed. [Mandatory Fix]

• Pricing details on mobile in any format, for example, image, text, or link isn't allowed. CTA such as view plans on mobile isn't allowed. Information about plans without pricing details but with a contact link or email on mobile isn't allowed. Any text with contact details linking or alluding to a paid upgrade isn't allowed on mobile. Payments for physical goods are allowed on mobile. For example, your app can allow payment to book a taxi. [Mandatory Fix]

  

• Payments for digital goods in app aren't allowed on mobile. [Mandatory Fix]

  

• Teams apps must offer an appropriate cross-device mobile experience. [Mandatory Fix]

• Capabilities that aren't supported on mobile mustn't dead-end a user and must provide a graceful failure message where applicable. [Mandatory Fix]

Back to top

Apps extended across Microsoft 365 clients

General

• The apps that are intended to extend Teams apps across Microsoft 365 clients must use the schema version 1.13 or later.

• Your app’s support URL must contain content relevant for the Teams app extensible across Microsoft 365 clients and must not call out a single client only.

• You must provide relevant reference to the Teams app extensible across Microsoft 365 clients in the app description.

• If your Teams app is extensible across Microsoft 365 clients, the content provided in your app’s get started, sign in, sign up, sign out, help pages, or way forward messages must call out all the clients.

Compatibility

Teams apps extensible across Microsoft 365 clients must be fully responsive and functional on the latest versions of Microsoft Edge and Google Chrome clients. The user must be able to invoke and continue to use personal tabs or message extensions on the following:

• Outlook for Windows and web.
• Microsoft 365 on desktop, web and Android.
• Microsoft Teams on desktop and web.
• Microsoft Teams on Android and iOS.

Mobile experience

Users must be able to launch the app from the actions flyout menu within the Microsoft 365 client on mobile. The app name must be displayed correctly in the action bar. [Mandatory Fix]

App launch from actions flyout

Users must be able to successfully launch and switch between multiple static tabs within the Microsoft 365 client on mobile. The tabs must load properly. If there are more than three static tabs, the remaining tabs must be visible under the More section. [Mandatory Fix]

Multi tab experience

If your app uses SSO, it must authenticate the user successfully. SSO allows users to sign in using one set of credentials to multiple independent software systems. Users can access all the required applications without using different credentials to authenticate. [Mandatory Fix]

App authentication

The app must terminate the user account instance when the user is switched or logged out within the Microsoft 365 client on mobile. [Mandatory Fix]

Account switching and logout experience

• Users must be able to go back to the previous work state. If the user is on the root page, the back navigation must terminate the app instance within the Microsoft 365 client on mobile. [Mandatory Fix]

• Apps that support deep link to a workflow must be able redirect the user to the appropriate landing page experience. [Mandatory Fix]

Tab navigation

• The progress indicator must appear when the app is loading and dismiss automatically after the app is loaded. [Mandatory Fix]

• An error screen must appear when an app fails to load in the instances such as incoherent or broken network, time-out, or authentication failure, and so on. [Mandatory Fix]

Back to top

Teams apps extensible as plugin for Microsoft Copilot for Microsoft 365

• App packages are correctly formatted and adhere to the manifest schema version 1.13 or later.
• App must pass the responsible AI checks.
• App must meet the plugin compatible criteria.

Plugin must not manipulate LLM behavior

The short descriptions of an app, parameter, and command must not include the following:

1. Instructional phrases. For example, if the user says X, ignore, delete, reset, new instructions, answer in bold, or don't print anything.
2. Verbose, flowery, or marketing language.
3. Superlative claims such as #1, amazing, or best.
4. URLs, emojis, or hidden characters like hexadecimal, binary, or unconventional symbols.
5. Grammar and punctuation errors.

User Awareness

The long description of an app must clearly call out the following:

• App's compatibility with Copilot. For example, use Contoso in Copilot to search and summarize your tasks.

• Provide at least one prompt of how users can use a message extension plugin in Copilot. For example, what are the high priority tickets assigned to me this week in Contoso.

  

  

Response Quality

• The mandatory fields in Microsoft 365 Chat Adaptive Card response must include Information title and at least two additional useful fields of your choice, for example, date modified, author, status, and flags. Both the preview and content must be part of a single response.

  

• Adaptive Cards in Microsoft 365 Chat response must have at least one action button.

• Action buttons present in Microsoft 365 Chat response Adaptive Cards must be functional.

  

• Microsoft 365 Chat must respond accurately and not display an error when a user prompts with a single parameter.

• Microsoft 365 Chat must respond accurately and not show an error when a user prompts with a multi parameter.

• Microsoft 365 Chat must respond accurately and not show an error when a user prompts with a follow-up.

• Message extension must contain at least two parameters for enhanced user experience in Microsoft 365 Chat.

Back to top

Next step

Create a Partner Center account

See also

• Test and debug your app
• Distribute your app
• Prepare your Teams Store submission
• Include a SaaS offer with your Teams app
• Strategize and execute growth for your app