Publishing SharePoint Add-Ins. Guide to avoid blockers.


Publishing your SharePoint Add-Ins into SharePoint Store is not as easy as it might look. There are some blockers that can significantly delay the process of creating your first SharePoint Add-In and destroy the motivation to create new Add-Ins. I uncover most of these blockers and ways to avoid them.


To publish an Add-In you need to complete the following steps:

  • Register a Seller Dashboard Account using your Microsoft Account (if you don't have yet)

  • Create a SharePoint Add-In

  • Submit the Add-In



Predictably, each of these steps has things to know for avoiding unnecessary delays and approval refusals.
I'll describe the hurtles that I found during the process of creating GoodPoint Add-Ins.


Step1. Registering a Seller Dashboard account



The Seller Dashboard registration is pretty straightforward, but it takes time (up to one month) for verification in some cases.
Make sure, you have a Microsoft Account, as it is required for the Dashboard registration. Once you have it, the Dashboard asks you to choose an account type:


  1. Individual Account

  2. Organization Account





Blocker #1: Verification of the Organization Account.
If you choose to act as organization in Seller Dashboard, be ready to be involved in external verification process and there is a high probability that you will be asked to provide some proof of company information. Be ready to provide documents like Certificate of Incorporation.
In contrast, Individual Accounts do not need verification and not affected by this blocker.

Blocker #2: Payment and Tax Information.
You don't need it, unless you plan to publish paid SharePoint Add-Ins.
Free Add-Ins can be published without payment and tax information in your account.
Here you will need the bank account information and fill tax forms. The approval process seems to be automatic and fast, but the bank account is the requirement.

By the way, are you aware what percentage of money you are going to receive from your Add-In sales?
Microsoft retains 20% (according the Agreement) of all your Add-Ins sales and you'll only receive a payment after 45-60 days after first sale and only if your balance is greater than $200. More info is available in Official Seller Dashboard FAQ.
Generally, you don't need to collect taxes like VAT/GST because they are automatically withheld too, but be careful here and double-check.

After your account and payment information are verified, you can proceed to Add-In creation and submit process.

Step 2. Create SharePoint Add-In


This step is relatively smooth, mostly because no one is checking your Add-In at this stage.
While you create a SharePoint Add-In, you need to keep in mind all the necessary validation rules to avoid your Add-In being rejected from Seller Dashboard.
There is a great Microsoft tool Office App Compatibility Kit to avoid many refusal cases. Just run it on your .app package when you are done developing.


Blocker #3: What is often forgotten in development stage:
The requirements below are must have, otherwise Add-In will be refused.


  1. You must have at least one Supported Locale in Manifest.xml file. By default, no locales are added in the VS project. If you don't really focus on any specific language or focus on English, just add English (United States) to locales.

  2. Increment version every time you submit same Add-In

  3. Open all external URLs in your Add-In in new window (with target="_blank" attribute). AppParts are rendered in iframes and opening a link in same window will affect the iframe only, which is a good reason for Seller Dashboard refusal.





I also strongly recommend to test your Add-In not only in SharePoint On-Premises, but also in SharePoint Online (if you plan to support it), as you may find a different Add-In behavior or even errors. For me, it was a surprise that SharePoint Online does not provide Request Referrer parameter and the Add-In web URLs are slightly different from On-Premises.

Have you created and tested your Add-In? Are all validation rules met?
Great job! Time to submit it for approval in the Seller Dashboard.


Step 3. Submit Add-In to Seller Dashboard


Although I cover all blockers, there is an official Checklist for this process. Make sure, you are familiar with it: https://msdn.microsoft.com/en-us/library/office/dn356576.aspx

Blocker #4: Submit process nuances.
Some information is actually redundant in the submit process, because Microsoft could take it from .app package automatically. However, if you make a mistake in these fields, the refusal will be imminent.
Here is the list to be careful:


  1. When you use Version number in Manifest.xml file, make sure you use absolutely same version number format when you submit Add-In for Approval. For example, 1.0.0.0 is not equal to 1.0 or 1.0.0 and Add-In approval process will fail. They check it every time.

  2. Add-In AppIcon.png in the VS project must match the icon in the Seller Dashboard.

  3. Don't use "Education" category for your Add-In, unless it is for teachers and students usage. Microsoft has special validation rules for this category.




Blocker #5: Why my Add-In is not in the Store finally? The Release Date secret.
Usually, the Store completes the approval and publishing process in 24-48 hours.
However, there is a small "bug" (or feature?) that may delay availability in the Store up to one year (!!!).
The secret is in Release Date field of your Add-In submit form. This field matters! The Store hides your Add-In until Release Date comes.
There is something wrong with Release Date parsing and the date 1/10/2015 can sometimes be considered as 1th October and sometimes as 10th January . My recommendation here is to always select the day of month greater than 12, it is a good protection against this bug. You will not be punished for using date in the past.


Conclusion


Avoiding all these blockers can significantly reduce the time of publishing your first Add-In.
Do you know any other blocker? Please share it in the comments!


Published: 6/11/2015 by Ivan Gorbadei
Back to Blog