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.
Pingback: Object Licensing with Microsoft Dynamics 365 Business Central - Kauffmann @ Dynamics NAV - Business Central/NAV Users - DUG
Pingback: Object Licensing with Microsoft Dynamics 365 Business Central | PA
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?
Do we need to sign extension even if we develop customer(Tenant) specific customization in 50000 Range to deploy into BC?
No, that is not needed.
We are developing an extension with the id range “70.000.000–75.000.000”. How can we do local development against a docker image while using the same range? OR do we need to maintain two different code base with two different ID Range because 70.000.000–75.000.000 isn’t supported for local development. (I assumed this based on my read above)
Just import your license in the Docker container. The navcontainerhelper powershell module has an easy way to import the license during creation.
What should be an object range for Test Extension in case if we are targeting AppSource? Should it be a part of object range which is provided by Microsoft for extension or could it be in 50.000–99.999 range?
It should be within object range provided by Microsoft for extension.
Thank you for reply.
In fact you can use both the object range for your app or the 50.000-99.999 range. Test extensions are only installed internally at Microsoft and you may use the customization range in case you run out of objects in the official range for your app.
If a an official reply (MS verified or tested)?
Yes, I got my info directly from Microsoft. Had a conversation about the same question a couple of weeks ago.
Thank you.
Pingback: Business Central – Licensing | PA
Hi,
what do you exactly mean by “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.”
Since when is the 50,000 -99,999 object range free? for On premises deployments we get a license with 10 Tables that goes from 50,000 – 50,009, if we need additional tables we have to purchase 10 Tables.
So are you saying for Business Central Online, Our Customers will get the Full 50,000 – 99,000 object range for free without any additional licensing fees as it is the case in On Prem. deployments ?
Thank You.
Yes, I’m saying that for Business Central online you don’t have to pay for any object in the customization range 50.000 – 99.999. That’s different from on-prem licensing. The online licenses are per named user and does not include a license file at all. Official information can be found here: https://community.dynamics.com/business/b/businesscentraldevitpro/archive/2018/10/17/which-object-ranges-can-we-use-with-microsoft-dynamics-365-business-central.
Please note there is a little catch in the document: The objects in this range are *currently* free of charge.
Please note that the customization range is only available for per tenant extensions.
It’s more clear now, Thank You
Hello,
Can we make tenant customization with range : 1.000.000–60.000.000 (ISV number range)
My compagny need to develop his ISV solution and also develop customer personalizations.
Regards,
BC online doesn’t allow to create per-tenant extensions in the ISV range. The only allowed range for per-tenant extensions is 50.000 – 99.999.
Pingback: ArcherPoint Dynamics NAV Developer Digest - vol 187 - Microsoft Dynamics NAV Community
Probably I have not searched well enough – although I think I did – but it seems since this post, and the official one you’re referencing in a reply to one of the comments here, that this has not changed, right?
Strange that there seems no similar kind of topic on doc.microsoft.