Microsoft Dynamics ERP: NAV Integration

By
Rossey Charleston
October 27, 2015

Wholesale companies running Microsoft Dynamics NAV for their ERP needs often wonder whether it is possible to integrate with third party systems such as sales order management. The good news is that it is possible; however, it’s important to understand what factors will determine whether a Microsoft Dynamics ERP integration is a project that can be accomplished in-house, or whether support from a Microsoft partner is necessary to make it happen.

Microsoft Dynamics ERP Background

Like its larger competitors Oracle and SAP, Microsoft has several product lines within Dynamics which are based on its acquisitions over the years. The instances or versions a given company could be running include:

  • Microsoft Dynamics NAV – formerly Navision. NAV is currently on release NAV 2016, and is the most popular of the Dynamics product lines.
  • Microsoft Dynamics GP – formerly Great Plains. Microsoft Dynamics GP is on version GP 2013 R2 and is oriented towards rapidly growing small and mid-market firms.
  • Dynamics SL – formerly Solomon, specializing in project based accounting for small and mid-market companies, typically in the general contracting and homebuilding space. Solomon, now on version 9.0, was acquired by Great Plains in 2000, a year before it was acquired by Microsoft.
  • Microsoft Dynamics AX – formerly Axapta. AX is currently on version AX 2012 R3 and is oriented towards large, global enterprises.

Microsoft Dynamics’ two most popular product lines are NAV and AX. Dynamics NAV was developed through Microsoft’s acquisition of Navision, and Dynamics AX was developed through the acquisition of Axapta, a collaboration between IBM and a Danish firm. Currently, Microsoft Dynamics encompasses about 5% percent of global ERP market share, behind SAP, Oracle, Sage, and Infor. Dynamics AX makes up the majority of global implementations, while NAV has greater market saturation within the United States. Dynamics NAV has the most United States market share of the two product lines due to its appeal to the mid-market and simplicity of installation.  However, the majority of Microsoft’s ERP revenues come from AX, due to the higher cost and complexity of each individual implementation.

NAV Technical Background

Each of the Microsoft Dynamics products is based on different coding languages - many of which are proprietary - and may have different protocols for integration with other applications. For the purposes of this article, we’ll focus mainly on NAV integrations. Microsoft Dynamics NAV is based primarily on .NET architecture running atop a SQL database and only works with the Explorer browser. It is available either as an on-premise installation, or in the cloud through Microsoft’s network of business partners. As is generally true of on-premise vs. cloud installations, the on-premise installations have more of an ability to be customized and extended than the cloud versions.

Customization: Proceed with Caution

Customizations are definitely doable with Microsoft Dynamics ERP products. Microsoft relies heavily on its extensive partner network to assist its customers with these projects. This is due in part to the fact that Microsoft uses proprietary rather than open source programming. In addition, some of the Microsoft Dynamics products are more complex than others; AX is generally much more complex than NAV, as are the organizations that use it, so implementations, integrations, and upgrades typically require a lot more support than is required by NAV. Although assistance from a partner is usually needed to customize, initial setup is fairly simple using the NAV wizard. This allows NAV to be set up and managed “out of the box” with minimal project management and specialized resources; it makes NAV a great fit for customers who may not have the resources to do a large-scale implementation effort, but rather need something that can be up and running quickly with minimal technical know-how. However, as businesses grow, their needs change and become more sophisticated, so some degree of customization may be required. This requires specialized skills and resources that most SMB’s – NAV’s core user base – don’t have. In these cases, Microsoft’s network of NAV partners is available to assist.

NAV Integration Options and Considerations

There are two primary methods of integrating Microsoft Dynamics NAV with third party applications. The first is via application programming interfaces (APIs) that allow two-way communication between Microsoft NAV and third party software. These APIs are typically developed and maintained by the third-party software application provider. The second is building a custom interface using Dynamics’ XMLport objects. This involves a system administrator putting NAV data into an XML format for exchange or integration purposes. Generally speaking, the API is by far the simpler of the two options. Integrating Microsoft Dynamics using custom code is not a small undertaking. Like most Microsoft products, NAV is based on proprietary code, which Microsoft makes available to developers for purchase. Because it is not open source, that severely limits what those who do not specialize in Microsoft development are going to be able to do with the software. In addition, custom code integrations are difficult to manage over time and as business needs change. This is why Microsoft prefers that these sorts of projects be handled by its network of trusted partners.

Determining Your NAV Integration Path

Now that you understand some of the general considerations that can impact your integration of Microsoft Dynamics with third party applications, you can create an integration plan for your particular situation. To do this, you need to identify:

  • Your business needs: what should the integration allow you to do?
  • Which version of Microsoft Dynamics, and what specific applications are you running?
  • Is there a Microsoft partner that offers a supported integration tool, or is an interface offered by the third party vendor?
  • If no integration tools are available, does your organization have the experience with Microsoft proprietary code to develop and support your own interface? If not, you will likely need to identify a partner organization to assist.
  • Has your current system been modified or customized? How could these impact your integration plans?
  • What are your future upgrade plans?

Generally speaking, the least costly option for integrating Microsoft Dynamics with third party applications––with the least possibility for long-term issues––is to use an API provided by the third party application vendor. If an API is not available, a Microsoft partner may offer a “plug and play” integration tool that can be used. Only when these options are not available, or when they do not meet your business needs, should custom interface development – with or without a partner – be considered. Do you have a need to integrate your Microsoft Dynamics ERP with a third party application? What challenges are you facing? We’d like to hear about it in the comments.