Skip to content

Microsoft Dynamics NAV Events vs Extensions

Microsoft continues to innovate on, and improve the functionality of, Dynamics NAV. As such, it is imperative for users to keep abreast of all the changes. One such change are Events and Extensions. At a high level, Events are the new way code is written in Dynamics NAV. An Extension is the way to install code using a PowerShell script, which is how Microsoft automatically scripts the installation of things you buy on AppSource for Dynamics365.

Events in Dynamics NAV

An event is like an integration point or “hook” into NAV. You can use it without seeing any of the other code in the product. It gives developers a prebuilt way to add a customization to NAV without touching any of the code from Microsoft. These events are sprinkled throughout the system in the really important parts like any time to change the value of a field, insert a record, release a sales order, post a purchase order, check a credit limit, etc.

For example, if you added a custom field to the sales order and wanted to require it be filled in before releasing the order, you could subscribe to the “On Before Release Sales Document” event and write your code separate from the base objects.

If developers have to modify NAV base code, they should use the hook pattern which will make upgrades easier. The new best practice is to modify the base code only as a last resort. Since all Events or hooks have not yet been developed by Microsoft, if an Event is needed but not available, developers should report this to Microsoft with the code requirement so that it may be included in future releases and/or cumulative updates.

Extensions in Dynamics NAV

An Extension is put together using the code the developer has written using the events. The extension wraps up all of that code (the custom field in the table and the page, and the code to make sure it’s filled in) with a shiny bow and puts it into a package that you could, for ease of explanation, just click on and install. Only code that has been written in one of the events can be part of the extension. If there is any other code added anywhere it’s not able to be installed as an extension.

When you develop with the extension model in mind, it doesn’t matter how you actually deploy the objects (extension or FOB file). Neither will impact the upgrade. The downside to deploying as an extension is that we can never see the code as developers. If we never had to add code to base objects (or couldn’t like in D365), it would not matter. We could deploy it however we wanted. But with NAV we obviously do that a lot, and it’s like developing while only seeing half of the picture.

A customer on traditional NAV should use an extension when there is zero possibility that they will ever need to customize it further. The world of most NAV customers is all about customization. As a developer, when you install an extension, the customer can use it, but it can't be seen when doing modifications. This makes debugging issues harder. It can lead to bad estimates about the time it will take to do the work. It can even mean that the customer needs to add additional things to their license that are unknown.

Base NAV ships with four (4) Extensions pre-installed that customers may be using.

For Dynamics365, Extensions is the way (the only way) to go. We don’t need to see the code. We’re not customizing on that level.

Upgrade Impacts

While there may be some minor exceptions, if something can be an Extension, it means that it can be imported into your NAV database without performing an object merge. If you use an Extension now, and later realize that you want to customize it, then you basically have to do a mini-upgrade for that piece of functionality. Object merge time during an upgrade is minimal nowadays. Testing is what takes the time, and you have to do that during an upgrade no matter which model you pick.

If a customer wants to upgrade NAV, and the Extensions do not work, the customer is SOL. The upgrade code related to the Extensions published on a customer’s database is the responsibility of the actual partner/ISV who built the Extension. No one else can access the code to fix it.

Yet another issue to consider with Extensions for an upgrade: since the custom objects in an Extension are not accessible, the data stored in those objects is not accessible as well. So if there are custom tables in an Extension, the data stored in those tables cannot be copied or archived to a temporary holding place during the upgrade. This too will require the originating partner’s/ISV’s participation. To be sure, Extensions should only be developed for as an ISV Solution (registered by Microsoft); otherwise a customer could have thousands of Extensions in their database within a year.

ISVs and Extensions

The goal for ISVs should be to move their code from NAV's base objects into Events. Once accomplished, the ISV can continue on the model of providing an FOB file to install. If that FOB files does not add code to the base objects they could also turn it into an Extension if they wanted to keep their IP private.

The con of no Extensions: there is a Merge process that needs to occur.

The con of Extensions: there are many for the developers since they have no visibility to the code. Developers cannot see the fields that were added, the objects that were added, or any of the code for the Extension. It is invisible to the developer, but impacts the VAR. You will always see the Event in the base object that is put there by Microsoft. You will never see anything that subscribes to that hook / Event if it is in an Extension.

Finally, our hope is that ISVs will include integration Events in their solution when they release products as Extensions only.

Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube