Dynamics 365 Business Central: Object IDs things to know

I think that today everyone of you knows that with Dynamics 365 Business Central we have the following rules for Object IDs:

  • 50.000-99.999: per tenant/customer customizations (no AppSource).
  • 1.000.000-60.000.000: RSP range for partners that have an ISV solution for on premise / D365BC. When used in Business Central these extensions are obtained as apps from appsource.microsoft.com.
  • 70.000.000-74.999.999: This range is only available for extension development and only in Business Central. These extensions are obtained as apps from appsource.microsoft.com.

There is however a rule regarding Object IDs that I see it’s not well known (or understood) from partners: CFMD range. I think there’s quite a confusion on this topic nowadays.

Many partners have actually their ISV solutions for Microsoft Dynamics NAV and they’re moving these solutions to AL and extensions for Dynamics 365 Business Central. Regarding ISV solutions (addons), Microsoft says that:

  1. if you have a CFMD solution for NAV 2018, you can use your CFMD addon range also for Dynamics 365 Business Central.
  2. This range is also valid for AppSource.

Many partners are then creating their new ISV application (released as AL extension) by using the same CFMD range as today with NAV 2018.

This is great (we can reuse our reserved object range and we don’t have to renumber all our objects), but actually there’s a big problem that starts appearing when using the SaaS version of Dynamics 365 Business Central.

The scenario is the following: I’m a partner and I’m moving my ISV C/AL solution to AL and Extensions. I’m developing it with my CFMD range because I want to go to AppSource in the next months. Today I have the X% of the addon functionalities available as extensions and ready to be used.

A customer signs a contract with me for Dynamics 365 Business Central SaaS. Starting with the “blank paper” is not what I want and I would like to deploy the functionalities I have ready NOW as extensions to this customer’s tenant (per-tenant extensions). Can I use the CFMD range (and so using the code I’ve available now)?

NO!! You cannot use your CFMD range with a per-tenant extension. If you want to use your CFMD range, you’re forced to go to AppSource. No more CFMD ranges deployed directly to a customer!

What happens now? You’ve essentially two choices:

  • Choice 1: Release what you have now to AppSource.
  • Choice 2: renumber your code with the per-tenant extension range and deploy the solution directly to your customer’s tenant.

The problems?

  • Choice 1: as a “long term solution” this is absolutely the best way to do. But if you’re not ready now for the AppSource approval process and your customer needs to start immediately, you have to say him that he needs to wait (for AppSource submission there’s an extra work to do).
  • Choice 2: renumbering the objects in the 50000-99999 range causes two main problems:
    • Your solution is “forked” and you need to maintain that per-tenant range.
    • When you’ll have the final solution published on AppSource, you can not easily “update” the customer’s tenant by removing the per-tenant extension and installing the AppSource one. You need for sure to handle object names conflicts (that must be avoided!!, you cannot have table 50000 called T1 and table 18XXXXXX called T1) and data transfer.

This seems quite obvious, but CFMD range management is an always more emerging problems at partner’s side.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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