Step 3 – Wizards | ForNAV App Building

Wizard pages are working on a revival from being almost forgotten. They were first introduced as form objects in Navision 3.0 as part of CRM. I instantly fell in love and started to create them for my own add-on.

Wizard pages have a few great advantages to normal pages and let’s go over them.

  1. Save Button – Even though it is not called “Save” the Wizard page is one of the few options in NAV you have to populate data, validate it and cancel the operation without a hassle.
  2. Overview – Essentially Wizard pages have fast tabs just like Card pages but the tabs are only displayed one at a time giving a clearer overview
  3. Validation – Wizard pages allow the programmer to clearly validate the contents of each fast tab before continuing to the next fast tab. Much more precise than normal database validation since with a wizard you can asume, program, for a really specifical order of entry.
  4. Explanation – On each page (tab) of the wizard you can write half a bible explaining to the user what to do. Be careful not to over do it since people these days are not used to sit down and read text anymore.

Almost lost

We almost lost wizard pages when Microsoft introduced the Role Tailored Client. There are only a few of them in the standard Application and the ones that do exist were in a part of Navision that Microsoft could not care less about since someone in Redmond had this briljant idea of replacing NAV CRM with Dynamics CRM which resulted in the name change of our module ro RM.

Fortunately for us some large partners had quite a few wizards in their ISV solutions and Microsoft “hacked” wizards in last minute using the Navigate page type.

Then we almost lost them again with the introduction of the Web Client. Again the Navigate Page was outscoped and the “Navigate Page” was changed to a Worksheet leaving only wizards as Navigate Pages.

Are you still with me here?

Now as part of the Saasification (a word that I hate) of NAV they are back and as always Microsoft is talking about it as if they’ve invented the freaking wheel, but they are over a decade old and the design pattern has not changed. Another proof of how smart the “old” patterns of NAV are and their validity.

Enough Navision history, get on with it…

For my ForNAV App I also wanted to make a Wizard page, just to prove how easy it is to make them and to be able to write this blog. I also firmly believe that wizards have nothing to do with “Saasification” but should be a normal part of any ISV solution.

Step 1 – Copy with pride

Wizard pages are suprisingly simple. The page itself is built on the table that you want to populate with the “SourceTableTemporary” property set to yes.

This gives a few restrictions. You cannot just build a wizard page on any table since many of the normal NAV tables have code in Validation triggers that assume you are doing something for real. If this is the case, or if you have a more complicated wizard you can make a decidated table and use that for your wizard.

DO NOT ABUSE TABLES! I cannot stress this enough. I tell it in every patterns class that I teach. Never, ever abuse any table as temporary table. Even for bespoke customer scenarios just create new ones. They are free, because Microsoft won’t check the customer license. We are not writing data to SQL.

For my wizard page I’ve stared with the Email Setup Wizard page (1805). This is a two step wizard page that has the base plumbing you need and if you copy it you make your life easier than starting from scratch.

Step 2 – Clean Up

The next step is to change the SourceTable property to your table (ForNAV Setup for me) and clean up the fields you don’t need. There is a bunch of stuff you don’t need and the compiler will help you find it.

After this step you should have somthing like this:


You now have a clean wizard with two steps. The images are already there but they only show up in the Web Client.

Step 3 – Change the descriptions

You need to change the explanations in the wizard. You don’t want your wizard to say, “Hey, welcome to email setup, let’s make it work”. You rather want something like this:


Step 4 – Change the code

You need to write C/AL code, which is cool, because C/AL is a great language.

First of all, you need to read the current values so the user get’s a headstart.


And you need to comment out some code temporarily until you’ve figured out what you want to do instead


Step 4 – Add your fields

In this step you need to add your fields and you need to decide how many steps you need. In my case two steps are fine, but the standard naming of the two steps in the email wizard are specific so I decided to simply rename them to Step1 and Step2. This allows me easier to copy and paste stuff to next wizards and makes the pattern more repeatable.


In my case I have two fields I want to setup


Step 5 – Add other stuff

In case of the ForNAV App I also want to change the values in the Report Selection so the Sales Invoice changes to the ForNAV Sales Invoice. This is an optional step although it does not make a lot of sense not to do it.

To add this in the wizard I need to create a variable and put that on a step


Step 6 – Finish and Store

The last step is to store the data in the real table and execute aditional code. In my case I need to replace the reports when this option is selected.


Off course, ReplaceReportSelection is a method of the Setup table, and those of you who were in my workshop will know that (TRUE) means HideDialog.

Step 7 – Assisted Setup

Wait, you said that Step 6 is the last! True for this blog, but you can also connect your wizard to the Assited Setup for Dynamics 365. This will be another blog.

The Result

The result is a nice step-by-step wizard that allows you to easily setup the App with some guidance.


Connect it

In my previous post I’ve created a Notification and I want the notification to run the wizard. I also want to run the wizard if somebody imports the fob file and runs the report from the object designer.

Lastly I want to have a default setup so I don’t want to go through the setup each time I do some playing around.

For this I’ve created an interface codeunit that I can run from everywhere. It asks me if I want to use default values or run the wizard.


This Codeunit I run from each ForNAV report and from the Notification.


Wizard Pattern

So here you go! You have the wizard pattern. Enjoy! Any feedback is appreciated.

1 Comment

  1. Kristof says:

    Nice work! thanks a lot for it!

    We are also working on quite some wizards at the moment I would like to place one small comment about the “EnableControls and NextStep”.

    Have you checked the Std. OData Setup Wizard (p6711) I think this one is kind of more smart to control the next page to show.
    It was quite funny to explore the different kind of Wizards that MS has made and the different “styles”.

    Oh and I have to agree on the importance of the “correct” temp table. We had a case showing headers – all loaded nicely in temp. The moment you pressed “delete” the triggered kicked in and erased all real table lines belonging to the header….

    Liked by 1 person

Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.