Dependencies: The Major Limitation of Dynamics NAV Extensions

Extensions for Dynamics NAV were released in NAV 2016, and were touted as a way to extrapolate all customizations out to an additional layer, leaving NAV's base code in tact and a nice, tidy and easy-to-upgrade platform. With the addition of events (which are fantastic), this sounded terrific and my development team and I were excited to get started with them.

However, there are some serious limitations with extensions, and it's critical to be aware of them before starting down the road of heavy NAV development, as they can leave you with a tangled, virtually unmanageable mess if not kept in check with a clear plan of how best to employ them.

The major one by far - and the subject of this article - is the poor design around field dependecies and customers' ability to make any changes to an extension "app" that any other app is dependent upon. In short, you won't be able to without first uninstalling any dependent app in order to make changes to the app you want. This causes a huge mess not only for development, but for deployments as the apps become increasingly tangled.

Tables in Extensions and their Persistent Problem...

If you build a custom table into an app, and that app is uninstalled and unpublished, no data will persist in that table. You will lose it all. This may be fine for certain scenarios. For example, we have a custom Dynamics CRM integration contained within an app/extension and which uses a number of tables to maintain transactional records between the various CRM and NAV entities. If we were to lose the data within that table by uninstalling the app, it wouldn't be a big deal as it's only used for logging and error handling purposes.

However, for most cases losing data in a table would not be acceptable, so build that into your designs.


When planning your development practices for a NAV 2016 and up deployment, do what is right for your organization, but do take the following into account:

  • Add custom fields and tables directly to the database, just as you would in older versions. This will prevent any issues with dependencies down the road.
  • With that, keep your business logic - i.e. the code that interacts with those fields - in the extension layer and make full use of events. This will keep things neat and tidy.
  • Be aware of the NAV licensing impacts that your apps/extensions will incur. You may cosume tables, codeunits, etc. when you're building apps which can alter the cost/benefit proposition, or at the very least become ugly in design.
  • Maintain a change log. This is key when it comes time to prepare for an upgrade. The change log not only identifies what is a customization, but what the business need was that prompted it, who requested it, etc. It is incredibly valuable down the line, when nobody can even remember what is or isn't a customization.


  1. Expected to form you a next to no word to thank you once more with respect to the decent recommendations you've contributed here.
    Expence Reports


Post a Comment

Popular posts from this blog

Preventing Negativity in the IT Support Culture

Configuring the Azure Active Directory Application Proxy to Secure Access to On-Premise Web Applications

Securely Exposing Dynamics NAV SOAP Services to External Client Applications using Azure AD App Proxy