After spending quite some time to go through the App publishing process for extensions for Dynamics 365 for Financials, I thought it would be a good idea to share my findings, thoughts, and experiences. It will be a multi-part series in which I will walk you through the process of getting an App published, look at the do’s and don’ts in development, and the packaging process.
This first part will look at the process around AppSource – the process and tool to get an App published. I have been reading different Yammer groups and forums and have talked to different people and realized that there is quite some confusion – and it’s not always easy to find the right people even at Microsoft to get the answers. To Microsoft’s credit, it is new and not all kinks are sorted out yet, but they are doing a great job in slowly improving the overall experience. Especially working with the app validation team has been intense but great – the team there is willing to help and go above and beyond to get quality apps published.
Let’s get down to it. How do you get an app published? There are a few things that you need to do. First, you must submit your app idea for approval. This is done on AppSource. Once you go to the submit page or “List on AppSource”, you will wind up here: List an App
Fill out the form, it mainly asks you about your contact information, company information, and then some information about your app. It is important that you select “Microsoft Dynamics 365 for Financials” in the selection “Choose the products that your app is built for”, do not select “Microsoft Dynamics NAV” – this would be a SaaS add-on app for NAV and not an extension for Dynamics 365 for Financials. It doesn’t matter what you select as the “App authentication method”, I usually select “Other” and specify “Microsoft Dynamics 365 login”. Once you submit the page, you will get notified that it can take up to two weeks until you hear back. Usually, it takes less time, I have always heard back within a few days.
Microsoft will send you another form to fill out, it is the “Microsoft Dynamics 365 for Financials App – Extension Request Form”. You must have your organization’s MPN ID as well as your PSBC account number ready. Fill out the first few rows with general information; the next rows are about your extension and app. You must tell them the name of the app, a short description, specify if it is a horizontal (productivity) or vertical (industry specific and which industry) app. Microsoft also wants to know the planned release date, the countries you want to release the app in (currently, only US and CA are valid), which is very important, how many objects you will need. If you are planning to create automated tests for this app, please make sure that you request more objects, since those tests should be in the app object number range. If you are planning on creating a “Library App” (common functionality used in multiple apps – packaged in an extension, but not separately published on AppSource), you need to submit a separate app listing request and define that it’s going to be a library app, you cannot include this in the object range of one of your “main apps”.
After you have sent the form back to Microsoft, you get the object range emailed back. The object range is in the 70 million range. This means that you can start developing your app (or renumber your existing app, if you have one created already). I will give you more information about what to pay attention to during development in another part of this mini-series.
Since your goal is to ultimately make money with an app listed on AppSource, you also must register for an account that Microsoft can pay you through. This is done through the Microsoft Dev Center RegistrationMSNPublishing Portal. It is important that you sign in with the same Microsoft Account you used for the Dev Center. Once you fill in the company profile under publishers, the system will find your dev center account automatically. Please make sure that your “Short Name” in the publisher info is the same name as your company name in your code signing certificate and is the same that will be used as the “Publisher” in the extension manifests (more to both of those things later).
You are finally ready to create your “offer”, which is the actual app. Go to “Madeira” and select “Create a new Madeira offer” (yes, it is not called Dynamics 365 for Financials yet, but hopefully will change soon). You can either follow the walkthrough or select the individual pages separately. It is important that the name you define for your offer is the same name that is defined in the extension manifest for the app. I am not going to explain every single field that can be filled out, I rather want to give you some idea of what must be filled out and how to fill this out.
First, you define the “Madeira” information. This is the place where you upload your navx file (“Extension Package File”). You can also upload a “Dependency Package File” (another app, your app depends on), a “Library Extension Package File” (separate extension that provides common functionality for multiple apps – must be in a separate object range and requested through AppSource as described above), and a “Test Automation Suite package” (automated tests).
You must have product documentation available online as a web page, which is marketing material, but it is required. Without this, you cannot publish your app. You also need to write up test cases for the app validation team at Microsoft and upload this under “Key Usage Scenarios”. It is important here that you are very specific and walk the tester through the setup and functionality of your app and test case step by step, include screenshots, and make sure you specify the specific data that should be used – for instance, use customer 10000 or item 1996-S. Make sure you use data that is available in the demo company for Dynamics 365 for Financials, it is different than the data available in the CRONUS company in NAV.
If you violate the coding guidelines or you need certain test accounts (like O365 accounts or Azure storage keys or anything like this) you must provide these for Microsoft and define them in a separate document and upload them under “Test Accounts”.
You also need to have online help available for your app and must submit this – the validation team does use the help as a reference guide. You can support your app in two countries currently and you would define these as a Json array: [“US”, “CA”]. You do not need to provide French translations for your app, even if you want to support your app in Canada. The “Version of your App” is the version in the extension manifest and must match – it has to be increased with every consecutive submission of new app versions.
Microsoft recommends to define “Dynamics 365” and “Financials” as the “Products that your app works with” and at least “Dynamics 365” and “Financials” in the “Search Keywords”. You do not need to submit demo videos for your app, but it is suggested. What is required, though, is at least one document, which should be a factsheet describing your app. Make sure that you do not use “Dynamics NAV’ anywhere – it is a different product from a marketing standpoint. It is also required to submit at least one screenshot of your app. The size must be 1280x720px or larger. You should take a screenshot from the Dynamics NAV web client, but make sure that you do not show the “Dynamics NAV” part of the title bar, so spend some effort in cutting out the proper screens.
You can also define how leads should be submitted to you. A lead is basically someone that looks at your app, they don’t need to actually install it, but from Dynamics 365 for Financials they must click on the app in the Extension Marketplace. You can pick between CSV, Dynamics CRM Online, and other destinations. The settings defined in “CRM Settings Json” vary by destination and are defined in a document on the “AppSource” SharePoint site. If you don’t have access yet, request access from your local Microsoft contact (I can also always help, if needed).
The next part is the “Support” part, which requires to define the name, email, and phone number of an “Engineering Contact” and the same information for a “Support Contact”. Both won’t be made public and are only for Microsoft to contact you. The “Support URL” however, is the one that is made public and should point to a website that defines how your app users can reach you for support.
Now it’s time to go to the “Publish” section and publish your app. First you click on “Push to Staging”, which will validate everything and give you errors, if you should correct anything. Once it is staged, you can preview your app on AppSource and make sure that it looks ok. If you want to make changes, you can always push to staging again. After it is staged, select “Request approval to push to production”. This will notify the App Validation team within Microsoft and their processes will start. Your app will be validated from a Marketing and Technical standpoint. The technical validation includes a code review as well as a functional testing. Please be aware that there are actual people sitting and working to ensure that your app can be published: Even if it is frustrating, be nice and remember that they are there to help you. Since the volume of apps submitted for approval is increasing, the validation team is rejecting your apps as soon as they find some errors and give you time to fix those and then re-submit. The entire process can take quite a while – do not expect an app to be published within a few days. At the point of writing this (end of January 2017), the apps in validation right now are for the March 2017 release.
As you can see already from this long blog about a rather small part – the “paperwork” around your app – it is not easy to develop and submit an app for Dynamics 365 and you must invest quite some time (aka money) into this to make it happen. It is not something that you can just do at night here and there, it requires dedication and commitment.
Let me know, if you have any questions or need assistance in your app publishing process, I will try to guide you through this somewhat confusing and complex process. The good part is: some of the steps described here only must be completed once.