Navigating Add-On Conflicts in Microsoft Dynamics 365 Business Central SaaS
The transition to Microsoft Dynamics 365 Business Central SaaS signals a shift for companies and their approach to ERP. As many companies migrate to cloud ERP to improve user productivity, outsource IT functions and hosting, and add more features to its ERP platform, they discover traditional assumptions about ERP no longer apply.
Before Business Central SaaS, Independent Software Vendors (ISVs) would create add-ons to Dynamics NAV that created customizations within the base ERP code to execute specific business processes. As Microsoft moved to a more modern architecture, the base code language was moved from C/AL to AL. Therefore, custom code and independently developed add-ons also needed to be rearchitected. Add-ons and customizations are now Extensions in Business Central, functioning outside of the base ERP code.
In Microsoft Dynamics 365 Business Central, add-ons for specific business functionality can be found in apps via Microsoft’s AppSource. ISVs now create their applications in AL code and hook into the Business Central platform. This shift from Dynamics NAV’s customized base code to Dynamics 365 Business Central allows Microsoft to continuously add new features via minor updates every month and two major releases each year, adding value to users through functional improvements and security updates. For D365 Business Central SaaS customers, it is possible for an add-on or other extension (customization) to come into conflict with the base code during these updates.
How to Spot Add-On Conflicts in Dynamics 365 Business Central
ISVs that offer apps on Microsoft AppSource are required to keep their add-ons up to date with the latest D365 Business Central release. However, ISVs code can be incompatible and become outdated as Microsoft continuously updates Business Central through its deprecated code efforts.
If an add-on is not compatible with an upcoming BC SaaS update, that add-on will be removed from your Business Central SaaS environment. This shouldn’t happen because Microsoft provides deprecated code plans to partners and developers of add-ons, including those on AppSource – typically two years ahead of when the code will be deprecated (removed from the Business Central code base). It is rare, but ISVs can lag behind, or a partner that developed a custom extension might not be following development best practices. When this happens, the incompatibility ‘blocks’ or breaks the Microsoft Dynamics Business Central 365 SaaS update. Since SaaS software is always on the latest version, the solution is for Microsoft to remove the offending code from your tenant.
Some developers also lock code during the development process, which is not a best practice. By locking the code, no one else can access it. If you have locked code, it could potentially break a future update.
If your code, whether custom or from an ISV, is in conflict with an upcoming Business Central SaaS release, your administrator and partner of record will be notified by Microsoft (IF you have asked Microsoft to inform your partner – this is a setting in your BC admin area). However, it is a best practice to create a sandbox environment and start testing early. A reliable ERP partner with development expertise can help your business avoid costly mistakes.
Testing Business Central Apps and Customizations
Once Business Central SaaS administrators and their partner of record are alerted to a breaking change, they need to remedy the offending code or remove the Extension where it resides within 30 days of the new release. As mentioned above, you or your partner can set up a testing/sandbox environment once Microsoft pre-releases the next software version. Some partners provide sandboxing and testing before updates go live, like ArcherPoint does with its Stay Current Assurance Plans for BC SaaS, to proactively (or reactively) handle any potential conflicts.
As developers write new code for BC SaaS customers, they will see what code Microsoft is planning to remove (deprecate) that will affect their extension/code. Responsible ISVs and partners will keep their code current and out of conflict with the base BC SaaS code. Your partner can provide support on how to navigate this challenge should it arise in your instance.
These scenarios are just for Business Central SaaS customers, as on-premise Business Central users are not continuously upgrading. However, Microsoft is aware of apps that you are using and will test Business Central SaaS updates for you to ensure there are no breaking changes for the upcoming release. Microsoft will install the apps from a customer’s database and move this code to the updated Business Central.
Proactively Manage Your Business Central SaaS Updates
The bottom line is that you need to proactively manage your D365 Business Central environment, planning for 10 monthly minor updates and 2 major updates annually. Have a process in place for testing and work with a partner that is capable of responding should you need assistance. Or outsource it to your partner to manage completely.