NAV 2017: Wizard pages now supported in Web Client


As of October 2016, NAV 2017 is the latest version of the popular ERP system. To complement the brand new features, NAV team worked on enhancing current features.

A list of the features not supported in NAV 2016 is located here.  Among them, NavigatePage was not supported in NAV 2016 Web Client, but it is now supported in NAV 2017 Web Client.

Let’s delve into creating a simple (yet fit for starting your own) NavigatePage and check it in the Web Client. Additionally, I will suggest a few cases when a NavigatePage is a good candidate to collect data from users and perform some processing in one screen.

The NavigatePage assumes the existence of the following objects (included in the demo):

  • Table 90001 “Generic Entity” with the following fields:
    • field_1 (Code10)
    • field_2(Code10)
    • field_3(Code10)

PK: field_1,field_2,field_3

  • Table 90002 “Generic Entity Comment” with the following fields:
    • field_1 (Code10)
    • field_2(Code10)
    • field_3(Code10)
    • Entry No.(integer)
    • Comment(Text80)

PK: field_1,field_2,field_3,Entry No.

  • Page 90001 “Generic Entity Card”
    • An action to launch the NavigatePage will be located on this page

NavigatePage details:


And the actions:


Note: To make the actions appear as buttons on the toolbar and the groups as tabs set each action’s InFooterBar property to Yes.

This simple NavigatePage will collect data(the comment) from the user in Step1 and when the user clicks Next will insert a comment and make visible Step2.

When user clicks Next, the system will:

  • validate the fields in Step1
  • Hide the fields in Step1 group
  • Perform Wizard action (generate the comment)
  • Show Step2 group

When the user clicks on Finish the page closes.

A few snapshots of the NavigatePage as it appears on the Web Client:


Launching Comment – Wizard action:


Click on Next will move the wizard into Step 2:


Standard NAV has a few NavigatePage pages. Check them out:

  • 5077 -> Create Interact
  • 5097 -> Create To-do
  • 5126 -> Create opportunity

If you have processes in which the users need to go through a few pages to enter data and create different entities, then NavigatePages are a great candidate for improving user efficiency and experience.

I used recently NavigatePages in two instances. Once, when I needed an unified screen to allow users to attach files (word docs, excel files, pdfs) in a Property Management AddOn. The documents were collected and attached to an email sent to the owner at month-end.

Another example was more recent when, with one NavigatePage, I was able to create records similar to a fixed asset, collect mandatory data for a purchase invoice and generate the purchase invoice for that record. Of course you need methods that will take care of generating the purchase invoice, its lines, general ledgers, vendor ledgers, dimensions. Moreover, assertiveness is needed to not end up with half-performed processes … But it’s possible to run your processes through a wizard page with an overall improved user experience and efficiency.

Sample code available here.


An asynchronous processing solution for MS Dynamics NAV


From the earliest to the newest NAV versions, long-running tasks are usually accompanied by a progress bar or windows with multiple progress bars. It’s developer’s preferred choice to inform the user with the progress of the launched task – an obvious choice to an hourglass cursor. There are plenty of business processes in any NAV database that do heavy processing. If we look into a posting task, NAV generates Add-On specific ledger entries, standard specific ledger entries, creates invoices and lines, adjacent records and so on. Therefore these tasks  can take a while and can keep the user session busy.

asyncThis blog is about a solution, my boss and I designed and used it on a few target processes, to allow users to immediately regain control of their session after the launch of a long-running task, while assigning the processing to a NAV background session. The results of the processing are recorded and easily retrievable by the calling page automatically by using PingPong Control AddIn.

PingPong info: msdnGunnar’s and Olof Simren ‘s blog.

How does our solution get implemented?

A table with entities to be processed named in the code sample “Generic Entity”. At the minimum the table should have PK fields. Our sample has three fields that are part of the PK: Field_1, Field_2, Field_3.


A card page for “Generic Entity” table named “Generic Entity Card” whose only action will launch the async process.

A factbox “Queue Summary Factbox” used on the “Generic Entity Card” to reflect the status of the last queued record processed. The status gets updated by using a PingPong Control AddIn.

A new table “Processing Queue”. At the minimum add enough fields to be able to locate later the record(“Generic Entity”) that launched the process. Additionally, an Option field, “Status” with at least 4 values: Queued, Processing, Error and Success and a Text field “Error Message” to record the errors that prevented the process to finish successfully.

A new codeunit “Process Queue” (whose Rec is “Posting Queue” ). In the Run function of this codeunit wrap the processing in a TryFunction to be able to rollback if errors are encountered.

If wanted you can add more fields to the “Processing Queue”. In our environment we have “Document No.” of the resulting Posted Sales Invoice and “Elapsed Time” to record the duration of the task. You could also enable Lookup on the factbox field to open a list page for Processing Queue table.

If you want to try our solution download it from here.