Microsoft Dynamics 365 Business Central: The Best Path for Creating and Maintaining Extensions

February 13 2020

How do you launch into the future with Microsoft Dynamics 365 Business Central? For most, the future lies in doing development with extensions, which have taken the place of traditional custom development from the Dynamics NAV era. In this new model, extensions deliver a uniform and continuously upgradeable code base, providing a more future-proof model that aligns with SaaS expectations.

Extensions vs. Add-Ons

Although more straightforward than traditional development of custom Dynamics NAV add-ons, creating and maintaining extensions for Business Central is not an easy task. The technological shift between add-ons and extensions is quite significant, requiring new processes, new technologies, and new architecture.

Previously, we created and sold add-ons based on localization and language. Today extensions are sold on AppSource to the global market and can be used anywhere in the world. Developers are challenged when creating a universal extension design, as it requires a holistic approach and the ability to adapt it across a broad audience.

Common D365 extensions challenges

The biggest challenge of all with extensions is the lack of a unified methodology on the topic. Rather than a set of standards, we have only different opinions from people who work in the industry. Every company thinks they have their own best path for creating and maintaining extensions, but there is no structured way to share their knowledge. Everyone simply figures out their own way by trial and error, which can be a tedious and time-consuming process.

To help reduce the time spent figuring out your best path to extensions, it is important to determine the direction you are taking before starting the process. Start by asking the following 10 questions:

1. Are you creating an extension as an independent software vendors (ISVs) or as a Value-Added Resellers (VARs)?

The difference between an ISV extension and a VAR extension is that ISV extensions are created as a product and VAR extensions are created as per-tenant customization.
For ISVs, the main focus is extensibility. This is because the end customer will want to allow for the addition of new capabilities. Therefore, before starting the process, you should answer which parts of the extension will you allow to be flexible and which parts you wanted to be fully locked in.
To tailor the solution for end customer needs, ISVs can choose from the following options:

  • Include the beneficial change in the base functionality of the solution and make it available to all end customers. This option is a good choice after making sure that the change will be beneficial to many users. However, it is important not to make the software too complex, as the more complex feature set becomes, the more advanced user skills are required.
  • Extend the solution by designing extensibility points for end customers. This option is a good choice when the change is beneficial to only a few users as the existing extensibility points allow users to add only the functionality that they need and not to get overloaded with the unnecessary feature set.

extensibility_points_graphSetup vs. feature set

When a VAR creates an extension, it is important to analyze the end-customers' business processes to find out how much they match the Business Central’s standard capabilities. If there is a mismatch, you need to ask if the end-customer is willing to change their business processes to fit the solution's capacity or you may need to program additional functionalities for the solution to fit the end-customers' requirements.

2. How many people will be working on creating the extension?

Before creating an extension, it is crucial to effectively organize the team to ensure smooth project planning and code management. The more people working on the extension, the more complicated DevOps processes become.

DevOps (development and operations) process

Without clearly established rules, there is an increased threat of making mistakes, such as developers overwriting each others' work. Therefore, it is very important to ensure a good 'source control' management process is in place.

Historically, you could choose whether to use 'source control' or not, but today there's no other option. Before starting, answer questions, such as:

  • How will the changes reach the testing stage?
  • Who reviews changes if there are no automatic processes that ensure system integrity?
  • What are the steps before starting work?
  • What should be done during the work process and what are the steps after the work is finished?

Once these questions are answered, assign people to the teams accordingly. 

 3. Are you creating a new extension from scratch or do you reuse C/AL?

Both ISVs and VARs should ask this question. Many solutions that we have now were created many years ago and have evolved over time, resulting in a lot of legacy code.

When considering creating an extension from an existing NAV customization, at the beginning you should analyze your solution to understand how much code and how many features it has and what makes your product unique. Maybe you can clean up unused variables in the solution. If every existing feature is necessary, then developing from scratch will take a lot of time and you should consider reusing C/AL to create an extension and get to market with Business Central quicker.

If you choose to reuse C/AL to transition to extensions, you can use the solution more quickly for Business Central on-prem, but it will be more complicated and costly to prepare for a release on SaaS. In this case, you should consider having a smaller version of your product on SaaS by offering only the essential functionality of the C/AL solution.

Before you begin, you should clearly determine your strategy in terms of SaaS.

Given the challenges of moving a C/AL product to extensions, if your solution has a limited scope, you may be able to more quickly develop everything from scratch and have a faster road to launching it for SaaS.

 4. Will it be an extension on SaaS or on-premises only?

When creating an extension on-premises, you can modify Microsoft's code and use .NET. But when creating an extension on SaaS, .NET isn't an option. Therefore, it is important to know from the start whether you plan to go on SaaS or if you want to remain on-prem.

According to Microsoft, soon, on-prem will have to use the same rules as SaaS. So, when you create an extension, the aim should always be to have the ability to distribute the extension through SaaS. In this model, you will always be able to publish on-prem, but not the other way around.

If you transition from C/AL to extensions to use the latest version of Business Central on-prem now and plan to go to SaaS in the future, you should look for alternatives of using .NET straight away. Otherwise, in the future, you will have to make modifications to ensure compatibility with SaaS, it will require a lot of resources because you will need to make significant architectural changes in the solution.

In all Microsoft ecosystems, there are many alternative products that allow you to reuse your own .NET, such as Power Automate. Therefore, technologically, you need to have a firm plan and future vision of where you are going and what are you going to do with .NET and base app modifications.

5. What will be your automated testing strategy?

You need to determine in advance whether you will do test-driven development or create testing scenarios after making an extension. Using test-driven development means the test is developed before the functionality. Usually, one hour of the development has to be covered by one hour of writing automated tests, which doubles the project size. Therefore this method ends up being more expensive. However, the plus side of it is that:

  • When you are releasing the solution it is automatically being tested.
  • Code quality is better when you test in advance
  • You can plan ahead and prevent mistakes

The other method is to create testing scenarios after creating an extension. It is a cheaper approach but there is a big chance that at the end of the project you might discover the functionality is not testable and the quality is low. Using this method, developers are frequently put under time-pressure and due to that, they take some important parts out of scope.
Even though the automated tests are more expensive, this method is worth it in the long run. When you are unable to test small changes to the functionality of a solution, you either have to go back to the initial version to make the test work, or you have to change the automated test to fit the current version.

If you do not have automated tests, over time different developers could make many changes to your solution, with unpredictable end results. This is especially true for VAR per-tenant customizations that are re-used and adapted to multiple clients.  Each client has slightly different solution versions and it becomes problematic to find and fix problems manually when doing upgrades later.

6. How and where will you do user acceptance testing?

When answering this question, you need to decide:

  • What is your release cycle?
  • Will everything be tested at the end of the project?
  • Will you work in an agile way and do everything in iterations?

An agile approach works well when starting from scratch because it allows your team to make progress while also remaining flexible to changing requirements, technical decisions, or other details. 

When working in an agile way, the changes are done frequently and due to that the tests of the changes are frequent as well. Frequent testing eliminates the probability of bugs and considerably reduces the risk of failure. When working in a non-agile way, namely Waterfall, the testing is less frequent and is done when all the development is completed.

Even though both methodologies have their advantages and disadvantages, working in an agile way allows to get feedback earlier and minimizes wasted investment.  If you need to do frequent testing, you should consider automated tests to reduce manual effort and ensure consistent quality. 

Waterfall vs. agile testing process

It is also important to determine the environment where you will deploy the deliverable for the user to:

  • Review the new software
  • Ensure everything is delivered as agreed

You need to decide in advance whose infrastructure will be used to set up a user acceptance test environment in order not to waste any time on discussions later on. Ideally, the process of uploading deliverables into the environment is automated and after each release the user can login, enter the environment, and check the latest updates.

7. How will you handle integrations?

Before creating an extension, you need to make an architectural decision as to whether to do a point-to-point integration or use intermediary products such as Azure Event Grid.

The point-to-point integration is more typical and is often an easier way to do integrations because the developer has a full picture. Event Grid is a more recent method with a more complicated configuration that requires extensive knowledge of Azure administration and Azure Event Grid operations.
Which method to choose should be considered on a case by case basis. Event Grid is a better choice for larger businesses, as they will have a higher load and it helps to ensure smooth processes. Whereas for SMBs with lower load, a point-to-point integration is more advisable.
In addition, you can choose to enable interim products, such as electronic document interchange (EDI) to handle computer-to-computer exchanges of business documents in standard electronic formats. You can also consider Azure Logic Apps services that help automate business processes and workflows when integrating apps, systems, data, and services.

8. Are you ready for Modern Client challenges when migrating existing IP to extensions?

The Modern Client consists of interfaces for the web client, Android apps and Windows apps depending on where you will use your solution. However, no matter where you use your solution — on a phone, tablet, or a laptop — the application has to function according to the same principles.
If you want to use Business Central 15, you have no other option but to use the Modern Client. This is not a problem when creating an extension from scratch because the developers have no choice but to align with the specifications of the Modern Client. The problems start when transitioning from C/AL to extensions because C/AL solutions built for the older Windows Client need to be changed over to Modern Client.
The Modern Client looks and behaves differently from the Windows Client, which can cause problems for the users who have become accustomed to a certain interface and way of working. Consequently, after migrating to extensions, users have to relearn how to use the system.

Otherwise, if you choose to recreate the Windows Client look and feel in the Modern Client, you need to put in additional development effort and planning, in advance, to remake the JavaScript for those Windows Client components to display information that is no longer supported in Modern Client.

9. How to SaaS-ify your IP to ensure a user-centered experience?

For the ISVs who want to publish extensions as an app, the app must fit within the D365BC SaaS platform. Apps have a very short time to impress the users enough to convince them to purchase. The more you are prepared for the customer journey, the more likely that the customers will purchase your software.

According to Microsoft, you need to invest as much time and effort into the user experience, as you put into functionality. Therefore, developers should think about how to make the app as intuitive to use as possible at the beginning of the process of creating an extension and focus on what the users need.

All the tasks such as notifications, on-demand configurations, user tours, demo data, etc. should be evaluated and estimated in advance, keeping in mind the user. Taking this approach, you can avoid surprise issues with the user experience.

10. How will you deploy extensions?

What happens when users want to use your solution or get a free trial? Ideally, it needs to be as effortless as possible for them to experience your solution. Therefore, it is important to plan the trial process in advance, including details like filling in default data or doing an initial configuration. Any parts of the process that do not need human intervention should be pre-configured, and the user should be informed through notifications about the procedure taking place. 

What's important to understand before starting extension maintenance?

To be compatible with the latest version of Business Central, solutions need to keep up to date with Microsoft's monthly updates and bi-annual major releases. If not, it can lead to unpredictable workloads and it is therefore preferable to have solution maintenance planned in advance.

Maintenance on-premises and on SaaS differ. When comparing both models, keep in-mind that with SaaS you cannot delay Microsoft updates once you get a notification. You have to convert. For the extensions on SaaS with small changes, the upgrades happen automatically. For the rest, you can prepare the trial version to check in advance whether the extension will work with the new version. To do that you need to set up an environment which every week receives the latest Microsoft version, runs automated tests and checks if solution is compatible with the newest version. Once the process is set up, everything happens automatically, and if you find any mistakes, you can fix them manually. Therefore, SaaS solution maintenance is very much based on automatization of processes.

By contrast, on-prem does not allow for as much automation. With on-prem you use other tools for maintenance, such as SQL Server Management Studio (SSMS). With SaaS you cannot use the same tools because you have very little administrative access from Microsoft to ensure you cannot see the data from other tenants.

What you can do on SaaS is get ready in advance by planning telemetry parameters that you will follow to maintain the solution. The telemetry parameters can be programmed according to the functionality of the solution to identify and explain problems that users identify during the testing stage. Once everything is set up, if the user reports a problem, you can always check the telemetry parameters and see additional information that helps to identify and fix the problem.

To summarize, it is important to consider all of these questions to determine your strategy before you begin an extension creation and maintenance process. Once you have a strategic map of where you are, it is easier to enter this new territory and not get lost. Likewise, once you know the problems, it is easier to overcome the barriers and head towards a future of success.  

FREE Membership Required to View Full Content:

Become a MemberLogin
Joining gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more, and it’s all FREE. You’ll also have the option to receive periodic email newsletters with the latest relevant articles and content updates. Learn more about us here
About Asta Lisauskaite

Asta Lisauskaite is a Product Marketing Manager at 1ClickFactory, a software factory company for Microsoft Dynamics Partners since 2009. 1ClickFactory helps to efficiently update, deploy, transform, develop and certify solutions for Microsoft Dynamics. The company is the largest provider of Microsoft Azure services for the Dynamics platforms and leads innovation with services for Dynamics 365 apps and Extensions. Many of 1ClickFactory services are based on a fixed subscription price and are easy to sell to end-customers. Find more info at and stay updated on 1ClickFactory LinkedIn page:

More about Asta Lisauskaite