Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Dynamics 365 Community / Blogs / Dynamics 365 Business Central for Partners / Which object ranges can we ...

Which object ranges can we use with Microsoft Dynamics 365 Business Central?

Kurt Juvyns Profile Picture Kurt Juvyns

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. 

0 – 49.999: The Business Central base application

This range is assigned for the Business Central base app functionality.  Not to be used by partners!

50.000 – 99.999: Customization ranges

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 

100.000 - 999.999: Localization range

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.

1.000.000 – 69.999.999: Registered Solution Program (RSP) range

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.

70.000.000 – 74.999.999: Business Central apps

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 here
These 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.

Comments

*This post is locked for comments

  • xgaronnat Profile Picture xgaronnat
    Posted at

    Hi,

    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 ...?

    Thanks, Xavier.

  • ChrisWilson Profile Picture ChrisWilson 5
    Posted at

    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?

    Chris.

  • Kurt Juvyns Profile Picture Kurt Juvyns
    Posted at

    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.

  • Vytenis Jakas Profile Picture Vytenis Jakas 70
    Posted at

    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.

  • dkatson Profile Picture dkatson 2,263
    Posted at

    Kurt thanks for that insights. But actually I became more confused after reading this blog, than was before:)

    We’ve streamed to the world, that 50k range will be free for SAAS. But now, we see that it’s only currently. May be you mean under that some monetizing model for per tenant apps? But i think that it should be monetized by a partner (if customer and partner agrred on that). Please clarify that.

    Secondly, splitting normal objects ids and extension object id’s is not good idea. In VSCode we assign only one id range for all objects inside of an app.

    In general, if MS want to push partners move to extensions, i’ll suggest next license models:

    On-Prem, hosted, IaaS

    - New C/Side objects : payed

    - Extensions: All AL objects (normal and extension) - FREE

    SAAS:

    -  Extensions: All AL objects (normal and extension) - FREE

    This will push partners and customers move to extensions and give MS much more value than some $ for objects.

  • Vincent Vancalbergh Profile Picture Vincent Vancalbergh
    Posted at

    It's sad to see us still chained to this concept of needing to pay for objects. In most ERPs you can make as much tables as you want and it really "sets you free". As a developer my creativity is really stiffled like this. For example: I could use the pattern where you use a table as a parameter to all a certain method (and yes, tables that never receive data have unofficially been considered free), but objects outside the licensed range are usually considered test-objects and will often be overlooked. This pushes us towards adding these as licensed tables forming an annoying hurdle. People argument "but tables hardly cost anything these days", but then why are we still being charged for it?

    In the end, it feels like a ploy to force everything into the AppSource with a small concession for table extentions because we've always been able to modify existing tables for free.

  • James Crowter Profile Picture James Crowter
    Posted at

    Hi Kurt,

    I'd like to support AJ's comments but also add that the statement 'Expect that customizations in the SAAS service will be monetized at some point in time' is not really satisfactory in a subscription world. Which client is going to be happy to sign up for BC when they know they will be commiting to have to pay this potentially unlimited commitment? In perpetual world they knew what the price was and what the ongoing maintenance was but in subscription world you saying we will start charging you more we are just not saying when or how much.

    This will be used to spread fear, uncertainty and doubt by compeditors and the on prem resistance. Please either kill it or say what it will be. I hope you kill it even if you lift the user subscription. I was hoping that BC finally slayed the perverted designs we see, just to save a few dollars on object licences.

    Thanks

    James    

  • ajkauffmann Profile Picture ajkauffmann 117
    Posted at

    Thanks for the overview, Kurt.

    A few questions:

    If your license already allows access to base objects in the application, like Customer table, why would you need to pay for extension objects for these? I read that the 80.000 - 99.999 range is reserved for this as 'free objects'. But why the split? Are you expecting partners to create new tables in the 50.000 range but tableextensions and pageextensions in the 80.000 range? Seems way to complex for me. Correct me if I'm wrong, but I think what you are saying is: a table in the 80.000 - 99.999 range will be monetized in the future, but a tableextension or pageextension in the same range will be free forever. Why not just make tableextension / pageextension always for free, no matter in what object range?

    Will there be any difference between license models for on-prem? E.g., named user license, used for Business Central on-prem, will never charge for 50.000 - 99.999 objects, the same as with SaaS?

    If 70.000.000 - 74.999.999 range becomes available for on-prem, in which license model and will they be for free?

    Thanks,

    AJ