Pages Menu

Posted by on May 6, 2022 in Everything Else

How can I make sure my Microsoft Teams app passes validation and is accepted into the Teams Store?

How can I make sure my Microsoft Teams app passes validation and is accepted into the Teams Store?

If you’re planning on having a Microsoft Teams app in the Teams Store, available for anyone to download and use – then you will need to pass app validation. I’ve previously blogged about this process but it’s time for an update, especially as the Microsoft Teams team have recently published guidance about avoiding having your app rejected.

The team have identified 15 of the most common reasons for app rejection:

Broken links, functional bugs, app crashes, and unexpected errors
App description
Violation of Microsoft trademark and brand guidelines
Microsoft 365 App Compliance Program
Violation of app icon guidelines
App name
Support link
Manifest schema
App UI
Valid domains
Localization information
Provider or developer name mismatch
Privacy policy
Terms of use
Credit: Microsoft

I’m not going to talk about them all, but I do want to highlight ones that I see people missing, or that aren’t always obvious unless you’ve experienced them. Some of them seem really basic (like the first one) but.. you’d be surprised!

Everything must work

This sounds like a no-brainer, but lots of apps get rejected because things aren’t working correctly. Broken links, apps that crash, confusing or nonsensical error messages all add up to a poor user experience, and the Teams Store team have a quality gate to stick to. This is not the place for “fake it till you make it, ship it now and we’ll fix it later”, and you should not start the validation process until you are 100% ready. Your app will be run thoroughly by real people, so it needs to do what it should, every time.

Mind your language

Another place where the Teams Store team maintain high standards is around how your app is described, via the descriptions and other manifest properties. These must be useful, accurate and of a good standard. You might be OK with the short and long description of your app being the same – but it’s an instant fail. Even things you might not think are important, such as spelling and grammar errors, can cause your app to be rejected. Specifically:

  • if your app relies on the user creating an account somewhere else, this information must be made clear in the description with links provided,
  • you can’t compare your app to another app,
  • your description should sell your app and highlight its value proposition.

It’s equally important that you understand and apply the Microsoft Trademark and Brand Guidelines.

I know, right. 🥱

However, even if you don’t think that as a developer this is your job, it needs to be done. If you don’t want to do it, find someone else who can read through and understand them. Here are 4 common violations of those guidelines that will lead to your app being rejected:

  • Using “MS” or “MSFT” instead of Microsoft.
  • Using “Teams” instead of “Microsoft Teams” the first time you reference it. After that, you can use “Teams”.
  • Including any Microsoft brand images, logos, trademarked text or other assets without first obtaining permission.
  • Making your app look too much like a first-party Microsoft app. (this can be a subjective opinion so you might still get rejected but you should avoid names, descriptions and logos that don’t make it clear it’s developed by a third party.)

Make it easy to test

As I said above, your app is going to be put through its paces by a team of human testers. There may also be some automated testing that takes place, but at some point someone is going to install your app in their test tenant and have a play with it.

“A massive 20% of #MicrosoftTeams apps are rejected because the testers didn’t have enough information to perform their testing.”

A massive 20% of #MicrosoftTeams apps are rejected because the testers didn’t have enough information to perform their testing.

To maximise your changes of having your app approved, you should make it as easy as possible for these people to use your app.

If they need test accounts, be sure to provide them and make sure they work. Include detailed instructions on any steps they need to take prior to testing, tips for using the application and any supplementary information you think will be useful. If in doubt, provide more rather than less.

Watch your schema versions

I’ve experienced this before. Any app that is being submitted to the Teams Store must conform to a publicly released manifest schema. That means not a preview schema. If you’re implementing new functionality or features, it’s very easy to move your app to a preview schema without realising and then not wait for those features to go fully GA before publishing.

You can check which version of the schema your app is using via the Developer Portal (1.11 in this example):

Finally, allow time in your product development lifecycle for the app submission process to happen, and for you to respond to any failures and re-submit. This step is very often forgotten and then marketing and communication strategies are delayed or impacted and everyone gets cross and shouty. The submission process will take as long as it needs to, and (other than doing all you can to avoid being rejected) there’s nothing you can do to make it go any faster. Make sure everyone on the project knows that submission is an important but uncontrollable step in the process.

Good luck with your next Microsoft Teams App Store submission!

Written by Tom Morgan

Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.
Buy the book: Building and Developing Apps & Bots for Microsoft Teams. Now available to purchase online with free updates.

Post a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.