NAV Apps are a new way to extend and customize a Microsoft Dynamics NAV deployment without the need to directly modify source objects. NAV Apps can be installed, upgraded, and more importantly uninstalled in an on-premises deployment or for select tenants in a multitenant deployment. With NAV Apps, customers can easily add or remove horizontal or customized functionality to their solution that upgrade much easier than past solutions.
NAV Apps support customizing most of the known concepts in a system, such as pages and tables. Biggest difference from classical development is, that source code modifications is not allowed. To work around this, programming events have been introduced in C/AL.
NAV Apps are delivered as a .navx package file. A .navx package contains the various artifacts that deliver the new functionality to the Microsoft Dynamics NAV deployment as well as a manifest that contains the name, publisher, version, and other attributes of the NAV App. You manage .navx packages with a series of Windows PowerShell cmdlets that are available in the Microsoft Dynamics NAV 2016 Administration Shell. There are also cmdlets available to ISVs and developers in the Microsoft Dynamics NAV 2016 Development Shell that help create packages.
 Note |
|---|
| NAV Apps work equally well in single-tenant and multitenant deployments. But the ability to make each tenant different is core to NAV Apps. |
How NAV Apps Work
NAV Apps are in the simplest terms the runtime application of objects and object deltas for a specific NAV App and tenant combination. When a NAV App is published to a Microsoft Dynamics NAV deployment, it compiles the objects in it against the current application database, and then, when the app installs for a tenant, stores the association and builds the relevant database schema. At runtime, the NAV App simply loads the associated objects for that app and tenant.
You can publish multiple NAV Apps to a Microsoft Dynamics NAV deployment and, in multitenant deployments, install any combination of published apps for each tenants. For example, let’s take a look at a scenario with a multitenant deployment with NAV Apps A, B, C, and D published to it. Each tenant can have their own unique combination of NAV Apps. The following graphics shows how tenants B, C and D have the same NAV Apps (App B and C) while tenants A and E only have one NAV App each, App A and D respectively. This provides for a great degree of customer functionality choice while at the same time maximizes the server hardware and administration workload.
In most cases, two NAV Apps can coexist and work independently of each other; however there is the possibility that two apps will try to modify the same object properties. In those cases, if the conflict cannot be resolved, the installation of the conflicting NAV App fails.
Using NAV Apps
NAV Apps as a concept are designed for horizontal add-ons that are additive by nature. While not limited to that premise, following that guideline will increase the ability of your NAV App to coexist with other NAV Apps. It will also ensure seamless upgrade across core application versions as well as NAV App versions.
At the core design of NAV Apps is the fact that code modifications are not allowed and never will be. This is intended to remove the code-merge task during upgrades and to increase the ability of NAV Apps to coexist with other NAV Apps.
In Microsoft Dynamics NAV 2016, not all core concepts are supported. We have focused on establishing a strong foundation for NAV Apps that includes the most important and most commonly used elements of an add-on, such as pages (modifications and full objects), tables (modifications and full objects), code units (full objects), and menu suites (full objects). For a full list, see the NAV App Capability Support Matrix.
Licensing considerations
Licensing is the same for functionality that is made available in an NAV App as in an. fob file. You must have the relevant license to create and export objects as TXT files. Similarly, your consumers must also have the appropriate licensing to use your NAV App.
 Warning |
|---|
| We strongly advise against using object IDs in the customization range (50,000-99,000) for NAV Apps that are intended to be distributed to multiple end customers. |
Lifecycle of a NAV App
By design, NAV Apps are intended to be more easily upgraded, and as part of that approach a NAV App leverages the concept of deltas that we introduced in the code upgrade process with Application Merge Utilities in Microsoft Dynamics NAV 2015. With this tool, you can create delta files for metadata modifications, which then can be used to merge into a target environment. NAV Apps take that merging concept to the next level where a similar delta is merged and compiled when the NAV App is published. The difference is that the merged object is loaded at runtime as opposed to being embedded in the core source object. Doing this also permits this merge to be effectively be reversed by simply uninstalling the NAV App, which removes that delta object from the system.
Development
From a development lifecycle perspective, a developer maintains their “app” as a codebase separate from the original, and then exports those modified objects as standard object .TXT files. Next, the developer runs the application merge utilities to create the deltas and then packages them with new Windows PowerShell cmdlets that are introduced in Microsoft Dynamics NAV 2016. To update an app, the developer simply repeats that process, incrementing the NAV App version number.
Packaging
An integral part of development is the final building of the package. This includes describing the NAV App with metadata like name, publisher, version in a manifest, and packaging that with the application elements of the NAV App such as DELTA and permission set export files. The end result of that process is called a package and has an extension of .NAVX .
Deployment
Management of NAV Apps uses a set of new cmdlets to publish an app to a Microsoft Dynamics NAV deployment, which makes it available for tenants to selectively install and use. NAV Apps can also be uninstalled for a tenant or at a higher level unpublished for the entire Microsoft Dynamics NAV deployment. Upgrade scenarios, either for a specific NAV App or the application for this Microsoft Dynamics NAV deployment, can be accomplished with less friction as NAV Apps and their functionality are self-contained and do not contain alterations to C/AL code, removing the need to perform a manual merge as illustrated in the following chart.
The following topics will go into more details of creating a NAV App, packaging it, and later deploying it to a target system.***