A client recently approached us to streamline their workflow of inputting client information into a pdf, Navision, and Illion. They were inputting the information manually and wasting lots of time.

We were happy to help them streamline this process. In a previous blog, we discussed the illion integration. Now we’re going to look at how we achieved the Navision (now known as Microsoft Dynamics NAV or Dynamics 365)

What is Navision?

For those of you unfamiliar with Navision, it  is a suite of Microsoft owned applications utilised for Customer Relationship Management.

The suite includes applications for sales, marketing, service, finance, HR, operations, and more. This suite helps people make better business decisions by accessing their data all in one place.

It’s great software, but when you need custom applications making them integrate with a solution this monolithic can be a challenge that drives the customisation costs higher than if you have software developed specifically for your business.

Why do we need to connect to Navision?

We need to connect to Navision because one of our clients currently uses it as their core system. The driver for this first integration  is to automate the process of inputting information into the CRM from the application. This is completed by generating a .CSV that matches the pre-existing Navision API requirements.  

How are we fixing it?

Inputting data in multiple places is time consuming and inefficient so we’re going to create a more user friendly approach that will input the information the user provides through automation. This should result in a reduction of manual data entry of nearly 67% for these tasks.

We are taking the following steps to improve the process:

  1. Create a new UI for customers to input their information
  2. Create a database optimised for communication with both Navision and illion.
  3. Connect with an API to Illion

The User Interface

First, we are creating a web interface for the application process. This replaces the editable PDF for the application, but a PDF is still provided at the end for the user to save in their records.

There is a different interface for corporations, individuals, and other types of businesses . We will go over both corporation and individual user interfaces to describe the differences.

Corporation UI

The company user interface looks like the page above, but has been altered to protect the identity of the client and their customer. Once the user inputs the ACN number, we verify the information with illion, which will provide the business name, industry, ABN, trading address (not shown), directors (not shown), and more which we will auto-populate to save people time.

Individual User Interface

The individual UI looks similar to the company page, but focuses on an individual’s information such as names, birthdays, occupations, etc. Because this information is more subject to change than most organisations, we only use the verification functionality at the current time.

New Database and API

The user interface connects to a new database we have created to optimise the system. This database is set up for efficient communication with both the illion system and the Navision system using industry best practices. From there, the database is connected to a .NET API, which has two-way communication with three other potential connections:

  1.  A process that converts the information to a .CSV when the application is complete. The .csv transfers to Navision’s API and is loaded into the database..
  2. The illion API  which allows information to be transferred from our client’s solutions to ilion’s database and back via XML integration. This makes it where the information can be viewed via the illion interface. This is discussed in the illion blog.
  3. Other companies API’s (if needed) for purposes of integrating with the clients application and then onwards to either Navision or illion’s databases..

If information were just going to Navision, we could make it where the form and the points match identically so that the integration is far simpler. WIth the information going into three different places, it increases the requirements we have to take into consideration. Navision is only receiving information from the web app through the CSV which makes it the simpler of the two integrations.  

ASP API 

The ASP API is specifically used for the transfer of information between the new database and the current Navision API which is the access point to the Navision Database. Connection to the Navision platform uses a CSV generated from the new Flying Donkey created database which had to be mapped in a way that matched up to the Navision API so the API will accept the CSV. 

 This API is necessary because of the age of the Navision API. Navision is a Legacy version on Microsoft Dynamics 365. Due to the cost associated with upgrading to the current versions, we decided that it is most efficient to connect to the Navision API.

To better understand the full operation of the system, we have provided the image below.  Once the information is in all databases, an end user can access the information they need from the new UI, illion’s UI, or NAV UI. This allows them to view just the information they need, but will eventually progress to where NAV is not necessary. To learn more about the Navision aspect of the integration, we have written a separate blog for it.

Integration of illion and Navision to UI/UX.

I hope this blog helps you understand some of the challenges associated with custom integrations. If you have questions, don’t hesitate to ask. Learn more on our Custom Integrations page.