Last week, before going to NAVTechDays I was asked to teach a ForNAV class in Switzerland. NAV2017 was just released so I decided to use that for the examples.

While doing some preparation I ran a few reports and it looked fine until I realised I could not design reports from the Windows Client anymore.

This is a very popular feature of the product where you can design reports as an end user without having to go through the development environment as long as you have access to the ForNAV Designer.

However, when I tested this earlier the “Open Designer” did not show up and I sent an email to my colleges in Denmark, not realizing I was going to confuse the heck out of them and waste a good portion of their time.

Application Area

Microsoft introduced Application Area as a new property in NAV2017 and if you just play with it without reading documentation it kinda looks as if it is not doing anything.

The reason for this is it’s architecture being hybrid between MetaData and AppData. This is kinda weird for a NAV property.

If we search for Application Area in the Windows Client we find this page

By default these values are blank

Where Used

When we do a where used of this table we find 86 usages. Most of them pages and one in Codeunit40 LogInManagement

APPLICATIONAREA

When we use GoToDefinition and end up in the table ApplicationAreaSetup again we can see a new keyword.

Syntax

This new keyword takes a text string that needs to be in a specific format using the # character. It uses the fieldnames in the setup table.

Yuck

The result of this is kinda like the Yuck in the Design Patterns session in NAVTechDays. The fieldnames in the application must match Metadata in the tables. In order to change the behavior of this feature everything is hardcoded.

#All

So we end up with application areas #Basic, #Suite, #RelationshipMgmt, #Jobs and #FixedAssets.

Yet if we look into the pages we seem to have #All as the most popular value. More than 1000 page controls have this value.

It seems that #All is a hardcoded value somewhere. Maybe Erik Hougaard can reverse engineer this in the engine.

Mandatory or not

At first it seems that this property is not a mandatory property. If I don’t populate it nothing goes wrong until…

Dynamics 365

When you open the Company Information page in NAV 2017 you can see a new option. User Experience. You can set this to basic and suite. But when installed the value is blank which is not a selectable option.

Don’t touch this!!

This “field” which is not a real field but the return value of a function is a real “WTF” experience. After you set this to Basic or Suite it looks like you cannot go back. Let’s try this and rerun our report.

Now the “Open Designer” option is gone. This is because I just started to use ApplicationAreas. Let’s look at the Application Area page.

When one of the flags in the setup table is checked, ApplicationArea becomes a MANDATORY property and all of my bespoke objects fail to work.

BIG YUCK!!

This feature is implemented because NAV2017 and Dynamics 365 for Financials share a code base but it means that EVERY SINGLE NAV 2017 customer can make his ENTIRE customizations disappear if someone forgets to put #All as a value in EVERY SINGLE control.

The new Microsoft

It took us more than a week to figure out what was wrong with the report. Not that we spend a week on it but my ForNAV colleagues could not reproduce it and we ended up looking at it at NAVTechDays.

We immediately took it to the Microsoft experts. They recognized the problem and told us they would look into it.

The reason I’ve put this on my blog is to avoid our entire NAV ecosystem wasting as much time as we did.