Maybe I’ve missed some announcements, and maybe others also blogged about this and I totally missed it. But so far I have not seen this message: with Dynamics 365 Business Central it is possible to customize tenants to individual needs.
What does that mean?
Tenant customizations
That means that you can create an extension for a single Dynamics 365 Business Central tenant which can be deployed directly, without going through AppSource.
In short:
- Dynamics 365 Business Central is open for customizations in the 50000-99999 range
- Use Visual Studio Code and the AL extension and the client designer
- Develop against a Dynamics 365 Business Central Sandbox or a Docker container
- Deploy the app directly to the production tenant
Background
Why would Microsoft enable this?
This is to enable the partner channel to deliver customizations for Dynamics 365 Business Central that fit customer needs. In fact, this is placing the end user in the center, because it is possible to create bespoke customizations on Business Central. It even allows the end-user to create tenant customizations themselves because you don’t need a development license at all!
Having said that, along with the positive aspects, we have to remember the flip side of the coin.
First of all, it is all about Extensions, AL code and VS Code. Which means that with Business Central we cannot do exactly the same as we can with Dynamics NAV on-prem.
Is that a problem?
Choices…
I could easily come up with more than a handful scenario’s that could only be solved by modifying source code. We are kind of spoiled by NAV and C/SIDE, aren’t we? But that on itself does not prove the approach of Dynamics 365 Business Central wrong. It just proves that it is a platform with different possibilities. With pros and cons. You have to make choices like: do I accept less or less optimal functionality, compared to what I could do with code customizations, can I still run my business with that? Or should I accept the costs of code customizations (don’t forget the hidden costs!) and stick to on-prem deployment for the moment?
By the way, I don’t want to say that Dynamics 365 Business Central is less optimal compared to on-prem deployment. From my experience, I can tell you that setting up the full Dynamics 365 experience like integration with Office 365 or PowerBI in an on-prem scenario is not that simple and straightforward. Want I want to say is that you have to make a choice what is more important: get the full experience of an online solution and accept limited customization possibilities or get the full flexibility of an on-prem deployment but accept the complexity and the costs.
Secondly, although it would be technically possible for end-users to create tenant extensions themselves, I would really recommend to handle this with care. To create extensions for Dynamics 365 Business Central you need to have in-depth knowledge of the architecture of the application. You don’t try to tune the engine of your car without proper knowledge, don’t you? So don’t customize the software solution you run your business with without exactly knowing what you do! The possibility to adjust Dynamics 365 Business Central to individual needs of customers is meant to be used by Dynamics 365 Resellers in the first place.
More information on customizing tenants can be found here.
Developing and deploying a tenant customization
Some important notes about developing and deploying a tenant customization.
You should develop with VS Code against a Dynamics 365 Business Central sandbox or using a Docker container. With a Docker container you will also have the possibility to develop for the next version.
Make sure to set the correct number range in your app.json and to apply to correct code analyzers. When you develop a tenant customization, set the number range to 50000-99999 and use the PerTenantExtensionCop code analyzer. When you develop an app for AppSource, then set the number range to the range you got assigned. And then you should use the AppSourceCop code analyzer. Look here for more info.
Deploying the tenant customization is done through the Extension Management page (no PowerShell needed!). You can just upload the extension package file. During this process, you will have the possibility to deploy for the current version or for the next version. More information about this can be found here.
Here are some screenshots of the upload extension wizard:
Who says that Dynamics 365 Business Central is a closed application? It’s rather the opposite!
What about licensing? How does the customer get the object added to their license?
What if the customer install other apps that have used the same object names or object numbers?
As far as I understand, the objects are already in the license. Business Central does not have a per customer license after all. I have not seen any information about special pricing for this in any way, so I assume it’s totally free.
You can’t install two apps with the same objects. Apps in AppSource have their own number range, that should be no problem.
Interesting about the license.
However the appsource apps controlled by MS does not apply to the 50000 to 99999 range. If the customer wants to upload manual changes they programmed themselves or had someone else do, they have to be careful with naming and object numbers in the 50000 to 99999 numbers. This is outside Microsoft’s control.
I wonder how MS will support this if they have uploaded objects in the custom range.
As always, you need to be careful with object naming. It’s highly recommended to use unique names. With Business Central that’s not different, compared to on-prem. Like importing fob’s with conflicting names is not possible, it’s not possible to install extensions with conflicting names. No matter in what object range they are. Same goes for field names in tables. It’s not Microsoft who is responsible, it’s the ISV / VAR who is responsible to use unique names.
Well, that sounds reasonable to a certain point.
Especially when Microsoft or ISV adds a new object within a new version for something that already exists as a customization and has exactly the same name as the (now new) object, it will definitely become an issue.
Pingback: Microsoft Dynamics 365 Business Central Tenant Customizations - Kauffmann @ Dynamics NAV - Business Central/NAV Users - DUG
Pingback: Object Licensing with Microsoft Dynamics 365 Business Central | PA
Thank you for the great article! It clarifies a lot. I have a question though. Can you give me an example of a personalization which cannot be done without modifying the source code? I recently implemented an on prem solution in which all the development was done using the Extensions v1 (without using the VS Code, but the Development Environment). I had few tricky requirements, even with gl posting redirection. However, I managed to do everything without modifying the source code. Only using extensions. So I wander what would be an example of the task in which you cannot avoid the source code modification. Thank you’
Thanks for the compliment, Marina!
If you managed to cover all requirements with Extensions v1, then you should be able to transfer it to AL code without any problem. In fact Extensions v1 was more limited than v2.
Examples could be code that you need to put in between base code. In a place where no event exists. If that is the case, then you should request an event at https://github.com/Microsoft/al/issues. There are certain areas in NAV which are quite complex (e.g. Item Tracking). Customization in such areas are more likely to end up with code customizations instead of events.
Having said that, with some creativity you can someimtes achieve unexpected results!
Good luck with converting your extensions to v2.
Hi. Great article. For a local extension does the app file need to be signed?
Pingback: Object Licensing with Microsoft Dynamics 365 Business Central - Kauffmann @ Dynamics NAV - Dynamics 365 Business Central/NAV User Group - Dynamics User Group
Pingback: Microsoft Dynamics 365 Business central – Resources - Waldo on Microsoft Dynamics 365 - Microsoft Dynamics 365 User Group - Dynamics User Group