Get used to the cloud

I have been sitting in on a few meetings with potential clients for Microsoft Dynamics 365 Business Central and a pattern has become clear. “We”, as the people in the NAV channel, were used to have a handful of go-to-answers, handling the usual customer requests. Most of these answers are rooted in modifying standard objects or selecting certain 3rd party ISV solutions. And a great deal of these answers needs updating.

Sure now we have all the *extension style objects and many changes can easily be made with those. But a lot of the changes we were used to making without much effort cannot be made easily with Extension V2.

And sure, there’s a lot of 3rd party ISV solutions in AppSource, but many of the existing NAV 3rd party solutions does not exist for the cloud yet, and even if the same ISV exist both for NAV and in AppSource it might not be the same product with the same capabilities.

So what’s the rambling all about? Well, it’s about educating our surrounding about the possibilities with BC in the cloud, the limitations, and the differences compared to NAV.

For the non-technical NAV and BC folks out there, this is what we can do on standard objects (tables and pages for now):

  • Add fields to tables
  • Add fields to (* most) pages
  • Add actions to pages
  • Add code to objects, but only access new fields, Rec and global functions that has been tagged to be exposed to us (*)
  • Hide fields or actions on pages (Set visible = false)
  • Move existing controls around
  • Change some properties on existing fields and actions

(*) Code on existing objects is complicated. Some objects, like matrix pages, relies heavily on global variables and local functions making it impossible to extend them in any meaningful way.

In many cases there are workarounds available to make most requirements work, but something that would be a one liner in NAV might be a much bigger effort in BC.

One option is to duplicate standard pages and replace actions to invoke our own versions. That’s a cheap way to get it to work, but it does add technical debt to the solution since you’ll have to keep your duplicated pages updated with the monthly updates from Microsoft.

So, to all of you non-technical people in our channel, be aware, that even though Business Central is just the next version of NAV, as soon as you enter the cloud or in a 100% extension based model on-premise, the rules have changed.

Reach out to me on Twitter @eHougaard and lets talk about the new challenges and solutions.

Hey BC developers, don’t get your streams crossed

Just had a funny little mixup that threw me off for a few seconds…

Let me explain. I’m working on a Business Central customer, in the cloud. I have connected Visual Studio Code to the sandbox instance with the standard launch.json setting:

I wrote some brilliant code and hit F5 to start debugging. Strange, the language has changed in BC, debugging should not do that?

Suddenly I realized, that I’m connected to a different BC instance, a session I was logged into before. BC does not complain about the extension I’m trying debug is missing from this instance or anything.

So beware, remember to log out and don’t get the streams crossed, because that’s bad according to Egon Spengler 🙂

If it seems that you cannot log out, make sure to remove all cookies stored for



Unable to compare operands of type …

Strange, I added a field to a table, everything compiled. But when modifying a record in the table I’m met with the following error:

Unable to compare operands of type NavCode with NavInteger?

This was in a NAV2018, late CU.

I have seen this kind of error before, usually because of objects not in sync (compiling everything will solve that)

The only change made, was that I added a single Text field.

The error is catch after the OnModify trigger. It’s not a debuggable piece of code that generates the error.

After several failed attempts to locate the source, I delete the field, recompiled everything, and added it again. Then everything worked?

Strange Day 🙂

p.s. Next time I’m gonna check the generated C# code …