Skip to main content
Submitted by Tom Hunt on 11 November 2019

7 Things I’ve Noticed About Doing Development in Microsoft Dynamics Business Central

7 Things You Need to Know About Developing in MS D365BC

I’ve been fortunate enough to be assigned to a Microsoft Dynamics Business Central implementation, and working in AL has been a whole new world for me. Coming back to Visual Studio and auto-complete after years of being in the old NAV development environment is nice. Years ago, I split my time between ASP.NET/C# development and NAV development, and it’s good to have Intellisense back. I had pretty well forgotten what it was like to have all those fancy bells and whistles after years of toiling in the bare-bones NAV development environment.

It is definitely an adjustment, though. In AL development, you’re (kind of) writing the text version of an object, instead of adding code to the compiled version of the object in legacy NAV development. (Please be aware: That explanation is not technically what’s happening behind the scenes for either AL or C/AL development. It’s just a convenient metaphor for how things feel.) I have observed that there are some little differences, and so here’s a list of things I wish someone would have told me when I got started doing AL development:

  1. First, the launch.json file is where you store settings for the startup of your compiled app. There’s a very important setting in here that can trip you up: It’s the schemaUpdateMode setting. The default value for it is “Synchronize”, which means you’ll be applying your changes to the existing database, and whatever data changes you make will be retained. But there’s also a “Recreate” value you can use. The “Recreate” option rebuilds the table definitions; you must use it for some table field changes, like when you change a field length or remove a field from a table.

    It’s VERY IMPORTANT to know that the “Recreate” option will NOT keep any data changes you make to records! This means that if you’re using “Recreate” and you add a sales order to the database, once your session ends, the sales order will be gone. It’s really confusing if you’ve never seen it before and no one’s told you about it. It could also be really useful if you’re trying to build a script that changes data and you need to test out how it works on a clean instance of the database each time, though.

    Within a set of parentheses, you separate parameters with commas for function calls and semicolons for function definitions. It took me a few days to get used to the way this works, but once I understood the difference, things got easier.
  1. On a related subject, it also took me a few days to get used to when I needed to use “begin” and “end” to mark a block of code and when I needed to use the curly brackets (“{“ and “}”) instead. You use “begin” and “end” to mark code, like IF statements and triggers and procedures. You use “{“ and “}” to mark definitions: object properties, DataItems in reports, page elements, table fields, etc. At least, that’s the way I think of it. Microsoft might have a slightly better definition.
  1. Learning the order in which all of the elements of an object are laid out can be difficult. For example, it took me some time to understand that for a table, the properties came first, then the fields, then the keys and triggers and procedures. If you’re transitioning from legacy C/AL development into AL, the best way to get to know this is to find the AL versions of the base system objects and look at how they’re laid out.
  1. If you’re trying to figure out which events to subscribe to, you can search for the Event Recorder and run it as you perform the task you’re trying to change. Event Recorder is extremely verbose, so when you use it, keep your recording to as small a number of actions as possible. For example, you might run the Event Recorder to see the events that run when you set the No. field on a Sales Line, and that would be something like a manageable amount of stuff to dig through to find your key events. If you try to run Event Recorder to see what happens when you create a new sales order, set the Sell-to Customer No., add a Sales Line, set the Type and No. values on the line, set the Quantity on the line, and then release the order, you should expect to be buried in events that you’ll have to dig through.
  1. If you’re using the web client, you can run lots of objects directly with URL parameters! This is easy. You just go to the address bar of your web browser and use the format in “http://[host name]/[BC Server Name]/?[object type]=[object number]”. For example, if I want to run page 42 Sales Order on my local development machine, and my BC server instance is named “BCServer”, the address I would use is “http://localhost/BCServer/?page=42”. Note that this works for tables and reports as well; you’d just use “table=36” or “report=10105” instead of “page=42” in your URL string. Codeunits and XMLports don’t work with this, but you can build a custom report to run those if you need to. (I have a report put together for this exact purpose; maybe I’ll put it in future blog entry.)
  1. Adding fields or actions to a base system table or a page is much more challenging than it used to be. Tables require you to make an extension, which isn’t that bad. But pages take some effort. For those, you need to know the name of the element you’re using to anchor your field (or action) and then base it on that. And existing element names can be difficult to figure out. Sometimes there are multiple elements on a page with similar names, like actions named “PrintReport” and “Print Report” and “&Print_Report”. You’ll need to be willing to use some trial and error to figure it out.
  1. Finally, be aware that printing from the Business Central web client is much different than printing from a dedicated client on a workstation. Printing in the web client means that the system creates a PDF, and then the user saves or prints that however they wish. This means that it’s much more difficult to force a report to go to a specific printer! If you’re doing something where that’s a requirement, like printing checks to a MICR printer or getting shipping documents to the dedicated warehouse printer, you’ll have to put in some significant extra work to make it happen – if you can make it happen at all.

I got the inspiration for the name of this post from our local TV talk show, which does a “Things I’ve Noticed” segment every week. I think their “things” are less practical (but more entertaining!) than mine, so here are a few videos you can watch if you want to waste some time.



If you have any questions about Dynamics NAV or Business Central for any version, contact ArcherPoint.

If you are interested in NAV/Business Central development, check out our collection of NAV Development Blogs.