My last blog post was about the possibility to create tenant customizations for Dynamics 365 Business Central. That raised some questions about licensing. Which I perfectly understand considering where we come from. With Dynamics NAV on-prem we have to license every single object. A base set of objects like Pages and Reports come for free with Page Designer and Report Designer, but if you want to have extra objects you have to first wire some money to Microsoft. So the question how that works with Dynamics 365 Business Central is a very valid question indeed.
Disclaimer: what I write here is the current status to the best of my knowledge. Microsoft could decide to place restrictions or even completely remove the possibilities. It’s unlikely to happen, but anyway, don’t shoot the messenger…
Dynamics 365 Business Central allows for three different number ranges to create extensions.
| Object range | Extension type | Available in AppSource | Available on-premise |
|---|---|---|---|
| 50.000–99.999 | Tenant customization | X | |
| 1.000.000–60.000.000 | ISV number range | X | X |
| 70.000.000–75.000.000 | Original AppSource number range for Financials | X |
Tenant Customization
Here we are talking about extensions created in the 50.000 – 99.999 range. Like I explained in my previous post. For those who find it hard to believe that all these objects are just for free: this is similar to the SPLA license which also includes this object range for free.
Extensions created in this number range cannot be published on AppSource. The only way to deploy a tenant customization to Business Central is to upload it through the Extension Management page. These extensions can also be deployed to a on-prem installation, as long as the license includes the objects being used.
ISV number range
An ISV can choose to create an extension in the number range they already have for their on-prem solution. This is the existing number range 1.000.000 – 60.000.000 for ISV’s and it requires an RSPA and CfMD to be free for the ISV. This number range is usable both on-premise and on Business Central.
This comes close to business as usual, right?
So ISV’s could choose to use their existing number range and convert (parts of) their existing solution to an AL extension. This AL extension will then be usable both on-premise and on Business Central. What’s more, it will be possible to publish these extensions as an app on AppSource. That means there is no need to split development between cloud and on-prem.
The pricing and payment can be similar as it is today when delivered directly to an end-customer. But when published on AppSource it is recommended to include monetization options like running in trial mode and integrate with a payment provider.
Please note that at this moment AppSource is not accepting extensions in the ISV range, but it will be implemented soon. Wait for communication from Microsoft about this. However, it should not stop you to start moving your solution to extensions!
AppSource number range
The number range 70.000.000 – 75.000.000 was the original number range for apps for Microsoft Dynamics 365 Finance and Operations, Business Edition (last time I use that in full writing…). This number range remains and should be used for apps that will not be available on on-premise. These apps are ‘born in the cloud’ so to say.
At this moment AppSource doesn’t have a payment process. The app needs to have a built-in payment process. Which is another topic I could talk for hours about…
More information
More information can be found on this landing page: Build Your Business on Dynamics 365 Business Central.
Or directly in these PDF files:
- Getting you started with Microsoft Dynamics 365 Business Central Add-on Apps
- Developing and publishing Microsoft Dynamics 365 Business Central Add-on Apps
Publishing on AppSource
This is the most preferred way to get an app. Both for the customer and for the ISV. For the customer AppSource is the first place where they can find solutions to extend Business Central for their business. They can trust that these apps have gone through a validation process. A vetting process that checks if the app is designed for Business Central, follows the UI guidelines, has the same end-user experience as the whole application and, last but not least, is backed by a support process.
For the ISV it is important to be on AppSource because it allows them to reach a wider audience. Microsoft will put AppSource in the spotlights and ISV’s get that marketing power for free. Being visible on AppSource also proves the ISV to be trustworthy, it comes with a positive image.
Keep in mind that there is a validation checklist to publish an app AppSource. The linked PDF’s above do have more information about the technical and marketing validation checklist. The technical checklist can also be found here.
Compare the rules for publishing and app on AppSource with the rules for CfMD and you will see a lot of similar requirements. There are also differences of course. For AppSource you don’t go through the CfMD process that is available for on-premise solutions. The rules are tested during the app validation process after you have published the app.
Final remarks
I wouldn’t be surprised if ISV’s and VAR’s are going to ignore AppSource because they think they can continue to do what they do today. Well, technically it is a difference because AL is not exactly the same as C/AL, we all know that. But from a business perspective it looks like they could work with Business Central as they do today with on-premise or private hosting.
But I consider that a wrong approach. It ignores the benefits of AppSource. Partners who do that do not take the opportunity to reach a wider audience. They sell themselves short by ignoring the potential volume they could have.
Another very valid question I got about these mix of extensions: what about naming conflicts? That’s a complex issue if you want to allow conflicting names and solve that silently in the background. The most simple solution is to not allow conflicting names. The same applies to Dynamics NAV, you can’t import a fob file with conflicting names, without manual steps, can you? With extensions it’s the same story, you can’t deploy an extension with an object or field name that already exists. So make sure to use unique names, something that ISV’s are already used to with their solutions.
Update: Dmitry Katson reminded me of the possibility to reserve your prefix / suffix for Dynamics 365. More information can be found here, including an email address to send in your prefix / suffix.
That’s it, I hope this clarifies object licensing with Dynamics 365 Business Central. I would say there are no reasons left to not even try to move your IP to AL extensions and try to get your part of the big pie Microsoft is cooking.