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 Must 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 passes Teams Store validation only after you've fixed the issues.
• Other guidelines are marked as Good-to-fix. For an ideal user experience, we recommend that you fix the issues, however, your app submission isn't 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. [Must 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

[Must 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

[Must 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. [Must fix]

• Prefix or suffix common nouns with the developer's name. For example, Contoso Tasks instead of Tasks. [Must 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. [Must fix]

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

• Must not contain profane or derogatory terms. The name also mustn't include racially or culturally insensitive language. [Must 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. [Must fix]
  • When uploading the app package in Partner Center, select the right Markets where the app is available in the Availability section. [Must 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. [Must 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. [Must fix]

• Don’t use parenthesis in naming to include Microsoft products. [Must fix]

• Developer name must be the same in the app manifest (previously called Teams app manifest) and AppSource. [Must 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. [Must fix]

• The app name in the app manifest and AppSource must match. [Must 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. [Must 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

[Must 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. [Must 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. [Must fix]

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

Similar platforms and services

[Must 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

[Must 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. [Must fix]
  • When users sign out, they must sign out only from the app and remain signed in to Teams. [Must 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). [Must 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. [Must 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. [Must fix]

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

Security

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

Back to top

Financial information

[Must 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. [Must 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. [Must fix]

Don't facilitate payments through an app for goods or services prohibited by General policy number 100.10 Inappropriate content. [Must 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. [Must 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. [Must 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. [Must fix]

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

Bots

[Must 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

[Must 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. [Must fix]

• Don't use top level domains such as .com, .in, and .org as a valid domain. [Must 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. [Must 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. [Must 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. [Must fix]

• OpenAPI URLs must be under partner control.

• Following External Domains aren't allowed: [Must 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

[Must 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

[Must 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. [Must 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. [Must 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. [Must 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: [Must 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

[Must 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

[Must 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. [Must fix]
• Bots must respond to user commands within two seconds or display a typing indicator. [Must fix]
• Message extensions must respond to user commands within two seconds. [Must fix]
• Notifications must display within two seconds of the user action. [Must 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. [Must fix]

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

• App must provide mechanisms for app users to report inappropriate, harmful, or offensive content to the developer by any of the following mechanisms: [Must 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. [Must 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. [Must 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. [Must 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. [Must 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

[Must 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.

Back to top

App manifest

[Must 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. [Must 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. [Must 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. [Must fix]

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

• The version number must be the same in the app manifest file schema and additional languages app manifest schema. [Must 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). [Must 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. [Must fix]

• The version string must follow the Semantic Versioning Specification (SemVer) standard (MAJOR.MINOR.PATCH). [Must 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 ... [Must fix]

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

• We recommend that you declare the Microsoft Cloud Partner Program ID (CCP ID), formerly known as Microsoft Partner Network (MPN ID) in the app manifest. The CCP ID helps identify the partner organization that builds the app. [Good-to-fix]

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

App icons

[Must 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. [Must fix]

  

  

• Your app package must include two .png versions of your app icon: A color icon and an outline icon. [Must 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. [Must 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. [Must 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. [Must fix]

• Your app package must include correctly sized and formatted icons. The icons must match the information in Teams Store listing metadata. [Must 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. [Must fix]

  

• Hyperlink contact details, get started, help, or sign up in app description. [Good-to-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. [Must 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. [Must 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. [Must 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:

[Good-to-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:

[Must 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. [Must fix]

• At least one screenshot must depict your app’s functionality on mobile devices. [Must 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. [Must 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. [Must fix]

  

  

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

  

• Provided screenshots mustn't incorrectly reference Microsoft Teams as MS, MSFT, or MS Teams. [Must 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. [Must fix]

  

• You must provide captions in your screenshots to let the user clearly understand the app capability. [Must 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. [Must 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. [Good-to-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. [Good-to-fix]

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

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

• The video must be available as a functional link. [Must fix]

• The video must be in the format https://www.youtube.com/watch?v=:id or https://youtu.be/:id for YouTube and https://vimeo.com/:id for Vimeo.

  

• 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. [Good-to-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

[Must 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

[Must 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

[Must 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

[Must 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. [Must fix]

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

• Supported languages must be displayed in the AppSource app description. For example, this app is available in X (X= localized language). [Must 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. [Must 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. [Must 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. [Must 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. [Must 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. [Must 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. [Must fix]

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

    

    

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

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

Views

• The sign in screen area mustn't use large logos. [Must 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. [Good-to-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. [Must 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. [Must 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. [Must 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. [Must fix]

  

  

• Horizontal scroll mustn't be present in an in-meeting tab. [Must 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. [Must 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. [Must 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. [Must fix]

  

  

  

  

  

• The user must have an option to go to previous work state. [Must fix]

  

  

• Horizontal scroll in Adaptive Cards mustn't be present in Teams. [Must fix]

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

  

Usability

• Content mustn't truncate or overlap within the tab. [Must fix]

  

• Users must be able to undo their last action in the tab. [Must 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. [Good-to-fix]

• Tabs must be responsive to Teams themes. When a user changes the theme, the app's theme must reflect the selection. [Good-to-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. [Good-to-fix]

  

• If your app functionality requires changes in settings, include a Settings tab. [Good-to-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. [Good-to-fix]

• Tab experiences must be fully responsive on mobile (Android and iOS). [Must 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. [Must 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. [Must fix]

• If your tabs contain a footer, ensure that you remove all links unrelated to app functionality from the footer. [Must 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. [Must fix]

  

• After the configuration experience, the landing page must show a collaborative view for the entire team. [Must 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. [Must fix]

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

  

• Configurable tabs must have focused functionality. [Must 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, date of birth, place, and designation instead of using multi-turn conversations. [Must fix]

• Any broken links, responses, or workflows in your app must be fixed. [Must 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. [Must fix]

  

  

• Bot commands mustn't lead a user to a dead end, the commands must always provide a way forward. [Must 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. [Good-to-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. [Must fix]

• Bots must respond to user commands without displaying a continuous loading indicator. [Must 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. [Must fix]

  

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

  

  

• Special characters such as slash (/), mustn't be prefixed to bot commands. [Must 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. [Must 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. [Must fix]

• Bots mustn't contain duplicate commands. [Must 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. [Must 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. [Must 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. [Must 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. [Must 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. [Must fix]

  

  

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

Tip

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

Bot first run user experience

• A bot in personal scope must always send welcome message or provide prompt starters. [Must fix]

  If you're using prompt starters, ensure the following guidelines are met:

  Prompt starters help users start a conversation with your bot. To enable prompt starters, the commands property in app manifest needs to be defined.

  • The bot must provide at least one command that enables the user to know about the value proposition of the app. [Must fix]
  • Prompt starters or commands must be functional and return responses. [Must fix]
  • Command description must be coherent and clearly communicate value of the command. [Must fix]
  • Prompt starters or commands must be relevant to the app's functionality. [Must fix]
  • The bot must have at least three unique prompt starters or commands. [Good-to-fix]

  If your app sends a welcome message, ensure the following guidelines are met:

  • 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 include configuration related information while sending 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.

  

  

• 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. [Must 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. [Must 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. [Must 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. [Must 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. [Must fix]

• Bot welcome message must clearly call out the limitations related to bot usage in the installed scope. [Must 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. [Must 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. [Must fix]

• Welcome messages mustn't trigger with every bot command. This is considered spam. [Must 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. [Must fix]

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

  

• App name in the welcome message must match the app name in the app manifest. [Must 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. [Must fix]

• Welcome message mustn't contain links to any app marketplace including AppSource. [Must 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. [Must 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. [Good-to-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. [Must fix]

  

  

• Bot messages in personal apps:

  • Don't send multiple messages in quick succession. [Must fix]

    

  • Send one message with complete information. [Must fix]

  • Avoid multi-turn conversations to complete a single repetitive workflow. [Must fix]

  • Use a form (or dialog) to collect all inputs from a user at one time. [Must 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. [Must fix]

  

Bot notifications

Bot notifications must include content relevant for the scope you define for the bot (team, chat, or personal). [Must 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. [Must 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. [Must fix]

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

• App name in the bot welcome message or bot responses must match the app name in the app manifest. [Must 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. [Must 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. [Must fix]

• Bots installed in collaborative scope must provide a user value in the collaborative scope. [Must 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. [Must fix]

• Preview images in Adaptive Cards in messaging extensions must load properly. [Must fix]

  

  

• Messaging extension response card must include the app icon to avoid end user confusion. [Must 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. [Must fix]

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

• You must include a way for the user to sign in or sign out from the messaging extension. [Must 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. [Must 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. [Good-to-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. [Must fix]

  

• Duplicate action commands mustn't be present. [Must fix]

• Message actions must allow the user to complete the workflow as intended without an invalid response. [Must 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. [Must 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. [Must fix]

Preview links (link unfurling)

[Must 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. [Must 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. [Must 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. [Must fix]

Search commands

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

  

  

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

  

Back to top

Dialogs

[Must 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. [Must 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. [Must 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. [Must 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. [Must 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. [Must fix]

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

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

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

• Meeting stage is a focused, intuitive, and collaborative participation canvas. Meeting stage mustn't embed the complete website experience. [Must 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. [Must 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 active Teams instance. [Must fix]

• Meeting apps must complete workflows within the Microsoft Teams platform without redirecting to competitor chat based platforms. [Must 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. [Must 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. [Must fix]

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

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

  

In-meeting experience

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

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

  

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

In-meeting tabs

• Must be responsive. [Must fix]

• Must maintain padding and component sizes. [Must fix]

• Must have a back button if there's more than one layer of navigation. [Must 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. [Must fix]

• Must not have Horizontal scroll. [Must fix]

  

  

In-meeting dialogs

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

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

  

  

• Must not use dialogs. [Must fix]

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

  

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

• Together mode: Ensure that you consider the following best practices for a scene building experience: [Must 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. [Must 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. [Must 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. [Must 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. [Must 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. [Must fix]

• Notifications must display within five seconds of user action. [Must fix]

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

General

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

Avatars

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

Spamming

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

Navigation and layout

• Notifications must adhere to the Teams activity feed layout and experience. [Must fix]
• When selecting a notification, the user must be directed to relevant content within Teams. [Must 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. [Must 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. [Good-to-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. [Must fix]

Back to top

Cryptocurrency based apps

You must demonstrate compliance with all laws where your app is distributed, if your app: [Must 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. [Must fix]
• All app capabilities must be functional and must work properly as described in the AppSource or app manifest long description. [Must 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. [Must 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. [Must 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. [Must 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. [Must 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. [Must 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. [Must fix]

  

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

  

• Teams apps must offer an appropriate cross-device mobile experience. [Must fix]

• Capabilities that aren't supported on mobile mustn't dead-end a user and must provide a graceful failure message where applicable. [Must 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. [Must 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. [Must 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. [Must 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. [Must 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. [Must fix]

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

Tab navigation

• The progress indicator must appear when the app is loading and dismiss automatically after the app is loaded. [Must 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. [Must fix]

Back to top

Teams apps extensible as plugin for Microsoft 365 Copilot

• 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 Microsoft 365 Copilot. For example, use Contoso in Microsoft 365 Copilot to search and summarize your tasks.

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

  

  

Response Quality

• The mandatory fields in Microsoft 365 Copilot 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 Copilot response must have at least one action button.

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

  

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

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

• Microsoft 365 Copilot 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 Copilot.

Back to top

Next step

Create a Partner Center account

See also

• Test and debug your app
• Prepare your Teams Store submission
• Include a SaaS offer with your Teams app
• Strategize and execute growth for your app
• Validate your app in Developer Portal for Teams