Object Licensing with Microsoft Dynamics 365 Business Central

30 Mar

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 rangeExtension typeAvailable in AppSourceAvailable on-premise
50.000–99.999Tenant customizationX
1.000.000–60.000.000ISV number rangeXX
70.000.000–75.000.000Original AppSource number range for FinancialsX

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:

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.

6 thoughts on “Object Licensing with Microsoft Dynamics 365 Business Central

  1. Pingback: Object Licensing with Microsoft Dynamics 365 Business Central - Kauffmann @ Dynamics NAV - Business Central/NAV Users - DUG

  2. Pingback: Object Licensing with Microsoft Dynamics 365 Business Central | PA

  3. Why will extensions in the 70.000.000–75.000.000 range not be available for OnPrem installations? Then I will recommend all ISVs using this interval to switch back to their old object numbers in the 1.000.000–60.000.000 range. I don’t see any drawbacks in using that, and I don’t see any advantage in using the new range. Or am I missing something?

    • The reason that Microsoft opens the ISV number range in Business Central is to not force ISV’s to maintain two object ranges. That’s something they learned after only having the 70.000.000 number range for online.

      Why not opening 70.000.000 – 75.000.000 range for on-prem? Don’t know for sure, in my opinion, technically it should be possible. The number range could be handled the same way as with the current ISV number range:
      For on-prem you need to have RSPA and go through CfMD (or pay a vast amount of money for the objects).
      For online you need to register with a PRA (Partner Registration Agreement) and go through the app validation process.

      The object number range is not relevant here in my opinion. It’s just that Microsoft first started with the 70.000.000 range and kept that the only range for a while. So it’s more or less historical and not for a technical reason I would say. Maybe they will change it in the future, who knows?

  4. Do we need to sign extension even if we develop customer(Tenant) specific customization in 50000 Range to deploy into BC?

Leave a Reply

Your email address will not be published.

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