Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
UPDATE OCTOBER 29th, 2018 - The content on this blog is updated! There are a few points of feedback which we want to address in this update:
1. Our journey with object ranges in perspective Just as we have done with the introduction of AL and Visual Studio Code as the replacement of C/SIDE and C/AL, we are also on a journey to modernize Object Ranges and transform customization opportunities with a more modern approach. This road ahead has a dependency on our mutual responsibility to move to AL and Visual Studio Code and will take a while as we need to consider both technical and commercial considerations. Object Ranges are both there to protect overlapping code (technical requirement) and there to protect your IP in the marketplace (commercial requirement). As we have already embarked on this journey of transition, you will notice from the blog port that now even more ranges have already made free of charge and now can deployed in more scenarios.
2. Remove the complexity around when to use which object ranges in the customization range and its cost involved. See below for an update on that in the customization ranges section.
3. Provide additional clarity on what monetization in Business Central SAAS will look like. See below for an update on that in the customization ranges section.
I wanted to provide some clarity on how you want to think about object ranges in Dynamics NAV and Microsoft Dynamics 365 Business Central. Which object ranges are used for what, which one have potentially costs associated, how do you apply for them and what changed with the launch of Business Central.
This range is assigned for the Business Central base app functionality. Not to be used by partners!
This object range is designed for resellers who want to customize the delivered solution to individual needs of a customer.
When implemented with Dynamics NAV 2018 or Dynamics 365 Business Central On-Premise, partner hosted or Azure IAAS:
The classic C/AL objects in this range needs to be purchased from the Dynamics Pricelist when implemented on premise, partner hosted or Azure IAAS. They are developed in the traditional way using C/Side.
New from Business Central Fall 2018 Cumulative Update 1 (planned for November) and NAV 2018 CU 12 (planned for December)
The AL extension (PageExtension, TableExtension) objects developed in Visual Studio Code and stored in the 50.000 – 99.999 range which extends objects to which you have modify permissions in your development license are free of charge. (For ex. When you want to extend the Customer table from the base app, you are required to develop an extension object and assign a unique object ID to it). Regular AL objects (Table, page, codeunit, report,…) needs to be purchased through Dynamics pricelist.
When implemented in Dynamics 365 Business Central SAAS: In the SAAS service, customizations are developed in Visual Studio Code and AL against a sandbox environment or a Docker container and loaded in the tenant through tenant customizations. The objects in this range are currently free of charge. Expect that customizations in the SAAS service will be monetized at some point in time. In line with the evolution happening on implementing customization on-premise. Customizations will NOT be charged based upon object costs. It will be based upon modern means which provide true value for the customer and opportunities for partners. Stay tuned for more info on this coming up. We appreciate your patience
The objects in this range are mainly designed when the Microsoft team localizes Dynamics 365 Business Central for a specific country or region.These objects cannot be used by partners.
This range is designed for your unique horizontal or vertical niche solutions which you will implement repeatedly . When you apply for a RSP solution, a unique range will be assigned to your solution by Microsoft. Terms in The RSP program details determine whether you need to pay quarterly fees.
However, if you comply with the ‘Certified for Microsoft Dynamics’ (CFMD) program requirements, one of the benefits of the program is that the quarterly fees on object costs will be waived.
New since summer 2018, Next to be able to implement these solutions on-premise, partner hosted or on Azure IAAS in Dynamics NAV and Business Central on-premise, these modules can also be implemented in Business Central SAAS and Microsoft AppSource. You will use the AppSource submission process for submitting.
The objects in this range are designed for developing Apps for Business Central SAAS which are made available through Microsoft AppSource. The code is developed in AL language using Visual Studio Code. The objects created in the app are free of charge! You request those object ranges hereThese Apps can be submitted through the AppSource submission process.
New from Business Central Fall 2018 Cumulative Update 1 (planned for November) and NAV 2018 CU 12 (planned for December
The apps, developed in this range and in AL can also be implemented in Business Central on-premise, partner hosted or Azure IAAS solutions. The benefit here is that you don’t need to maintain multiple object ranges.
I'm developping a customization in form of extension (not C/Side) for a customer hosted/in IaaS, does-we need to purchase objects for regular objects in the 50.000 - 99.999 range (table, page, codeunits, ...) ?
If so, what happen when we will move later to SaaS ...?
Kurt, We have been following this thread with interest as we are currently planning our project to migrate our current NAV IP to extensions and want to ensure we do this in such a way that it complies with AppSource requirements. Reading the updated posting below I would appreciate confirmation/clarification of a few points.
1. Our current object allocation in the 1-70 million rage can now be used to submit the extension for submission to AppSource? This helps is as we do not need to renumber our existing extension developments to 70 million but we continue pay for these objects under RSP as we have not had this IP CFMD'd.
2. For future BC "onpremise" clients we can develop the extension in the 70 million plus range and this object allocation will not be charged for? Is this the current position and might change has been eluded to in some of the other postings to this thread? I would certainly echo the sentiments expressed below about how an object based charging regime can have a negative impact on good design.
3. I have seem some discussion in this thread regarding placing extension objects in a different number range to new standard objects. From a design perspective this does not feel right. What is the current position on this?
Thank you all for the provided feedback so far - We do appreciate having this conversation and we value your input!
Just as we have done with the introduction of AL and Visual Studio Code as the replacement of C/SIDE and C/AL, we are also on a journey to modernize Object Ranges and transform customization opportunities with a more modern approach.
This road ahead has a dependency on our mutual responsibility to move to AL and Visual Studio Code and will take a while as we need to take into account both technical and commercial considerations. Object Ranges are both there to protect overlapping code (technical requirement) and there to protect your IP in the market-place (commercial requirement).
As we have already embarked on this journey of transition, you will notice from the blog port that more ranges have already made free of charge and now can deployed in more scenarios.
When we are heading to Directions EMEA next week, we look forward to continue this conversation on this topic with you over there.
I second the opinions of Arend and Dmitry that splitting extension objects into two ranges is confusing.
Also, we were as well under impression (and that AL extension objects, SaaS or On-premise, will be free; now you are saying there's possibly some monetisation coming? The paid-for objects in NAV world were always an unnecessary design burden, please don't bring this over into AL era. The model which Dmitry described is the same were expecting and communicating to our upgrade partners as well.
Business Applications communities