Tech Adventures in Business Central | AL Development & AI Solutions

Format Cheatsheet

Tue, 07 Oct 2025 10:00:00 +0200

This is a very quick cheatsheet for all the different formats that you get out of AL using the Format() function with various format options.

I’ve recently been trying to again find the format that returns the GUID value without the curly braces, and as I didn’t want to test all the options again, I finally created this cheatsheet for myself. Maybe it will be useful for you as well.

Format 8 was omitted from this table as it produces no meaningful formatting for any data type.

Click on any cell to expand and see the full value.

Note:
Values marked with an asterisk (*) are language dependent and to make that obvious, I left them in Spanish.

Data Type	Format 0	Format 1	Format 2	Format 3	Format 4	Format 5	Format 6	Format 7	Format 9
DateTime	10/07/25 02:30 PM	10/07/25 02:30:52 PM	10/07/25 02:30 PM	10/07/25 02:30:52 PM	N/A	N/A	N/A	N/A	2025-10-07T11:30:52Z
Date	10/07/2025	10/07/2025	100725D	25/10/07	*Octubre 7, 2025	100725	251007	*Oct 7, 2025	07/10/2025
Time	2:30:52 PM	2:30:52 PM	143052T	N/A	N/A	N/A	N/A	N/A	14:30:52
Guid	{FDBEA7C4-9205-4A3A-998E-D7B020529BC1}	{FDBEA7C4-9205-4A3A-998E-D7B020529BC1}	{FDBEA7C4-9205-4A3A-998E-D7B020529BC1}	FDBEA7C492054A3A998ED7B020529BC1	FDBEA7C4-9205-4A3A-998E-D7B020529BC1	(FDBEA7C4-9205-4A3A-998E-D7B020529BC1)	{0XFDBEA7C4,0X9205,0X4A3A,{0X99,0X8E,0XD7,0XB0,0X20,0X52,0X9B,0XC1}}	N/A	{FDBEA7C4-9205-4A3A-998E-D7B020529BC1}
Decimal	1,234,567.89	1234567.89	1234567.89	1,234,567.89	1234567.89	N/A	N/A	N/A	1234567.89
Boolean	*Sí	*Sí	1	N/A	N/A	N/A	N/A	N/A	TRUE
Option	*Pedido abierto	*Pedido abierto	1	N/A	N/A	N/A	N/A	N/A	1
Enum	*Pedido abierto	*Pedido abierto	1	N/A	N/A	N/A	N/A	N/A	1
Duration	*1 hora 1 minuto 1 segundo	*1 hora 1 minuto 1 segundo	1 2 1 4 1 6	N/A	N/A	N/A	N/A	N/A	P0DT1H1M1.0S
RecordId	Frmt. Tst. Tbl.: 1	Format Test Table: 1	Frmt. Tst. Tbl.: 1	N/A	N/A	N/A	N/A	N/A	[MyCompany.Tables."Frmt. Tst. Tbl."]: 1
DateFormula	*1T+2D	*1T+2D	<1Q+2D>	N/A	N/A	N/A	N/A	N/A	1Q+2D

Copilot is just a fancy autocomplete (vol.2)

Sun, 21 Sep 2025 10:00:00 +0200

A few weeks ago, I was asked if I’d have time to deliver the “Copilot is just a fancy autocomplete…“ session from this year’s BC TechDays again for one of our partners at their internal event. As I was preparing, I realized that even in the span of 3 months since the session, my workflow with AI has again changed so much that maybe it’s time for a part 2 of the blog post.

The “fancy autocomplete” story started at the beginning of the year with the part 1 blog post. All the points from the blog post then matured into a session at BC TechDays 2025, which is also now available online.

The session covered some best practices to get the best results out of the fancy autocomplete, but then quickly turned towards other capabilities. Copilot Edits take the center stage, as the next step, and we later progress into agent mode, and compare VS Code to Cursor.

If you haven’t seen the session yet, or if you’re at the start of your Copilot journey, I’d suggest you first take the 90 minutes to watch the session. This blog post picks up where the session ended.

The most significant change is that, during the session, I take a stance that Agent mode is nice, but Edits is where our focus should be. Realistically, during the last 3 months, I’ve exclusively used only Agent mode for both vibe-coded projects and AL tasks, and I don’t even look at Edits anymore.

I do believe Edits will eventually be removed. Cursor has already removed its “manual” mode, which was the Edit equivalent. But for the time being, I think they can still have a purpose. If you’re entirely new to the Copilot journey, especially if you’re a skeptic, it can be a nice, slower introduction to how AI can help read and modify multiple files at scale, compared to the Agent mode, which will have more “a mind of its own”.

I already introduced Agents during the session, but here it comes again. Agent mode is similar to Edit mode, except that it tries to find its own context for the changes it needs to make, and it has access to “tools”.

I made a big deal in the session about taking control of your context. But it feels like that’s less important now. If you have specific files that you want the agent to look at, by all means, pull them in. But also rest assured that it will do a pretty good job at finding the files on its own:

It’s able to do that because it has access to tools. It’s no longer just reading content and generating new tokens. It can take action within your IDE, like search for files, run commands, do web search, check errors and warnings, …

We’ll return to tools when we discuss MCP Servers, but for now, know that this is the “secret sauce” behind the power of Agent mode.

Agent Settings for Best Results

To have the best results with Agents, here are two settings you should enable:

Todo List Tool

This tool will allow the agent to create its own to-do list as it works through a more extensive task. It helps the agent “remember” what it has to implement throughout the length of a more extended conversation. Here’s how it looks:

As it goes through the individual Todo items, it marks them as completed, helping it maintain focus on the current task.

Max Requests Setting

By default, the value is set to 15 (or at least it was, when I changed it for myself). After 15 steps, the agent stops and asks the user, “Do you want to continue or stop the process?”. Fifteen steps is not a lot of steps. I quickly grew annoyed at having to keep pressing ‘Continue’ on larger tasks, so I changed mine to 100. I haven’t seen an interruption since, and I’m free to browse LinkedIn as the agent implements larger items of my work. :P

Copilot Instructions

If you want to get the best results with the agent mode, you should couple it with copilot-instructions.md. The instructions file will be appended to each request you make to the agent. During the session, I explained how you can use this file as a “memory” file, to make sure the agent codes the way you would. Do you omit spaces in object and field names, but agents use them? Put it in the file. Do you want to have explicit parameters with internal functions (Insert, Modify, Delete), but the agent skips them? Put it in the file.

When creating these files, you don’t have to start from scratch. Dmitry Katson shared his instruction files with the community. I keep mine here, but they’re far less extensive, as I’ve generally had good experience with the proposed code, with only minor adjustments needed that I keep in the instructions file.

However, something that I haven’t mentioned in the session, nor captured in the above instructions file, that I think should be part of every single repository is a project overview. Every project should have an explanation of what it’s about, what the architecture looks like, and the main patterns used. And even there, you don’t have to start from scratch. A few releases ago, the VSC team added the action to generate the project overview instructions:

When executed, it will prompt the agent with a preset prompt to scan the workspace and create (or update) the instructions file with the project overview:

And here are some of the results

Considering how easy it is to include an overview, I don’t see a reason why you wouldn’t go and include it in your repos right now. :P

Models

Next, I want to touch on the topic of models again. My stance remains the same; Claude models appear to be the best for AL. However, we’ve recently received two others that I sometimes like to switch to, especially when Claude appears to get drunk and proposes stupid solutions (this one was suggested to code hand-crafter AJ Kauffmann):

The models I like for AL are:

Claude Sonnet 4 – My default, best results, most consistent, overall the best experience.
GPT-5 – After poor AL results with 4o, 4.1, o3, 4.5, this is the first GPT model that I can easily trust to get things right. I like to use it as an alternative to Sonnet when I have tasks that require more of an analysis of a codebase. Apparently, Copilot was also tweaked to work better with this model, as evidenced by these two settings I found (but I haven’t noticed too much of a difference)

Grok Code Fast 1 – This is the only “included” model (meaning “free”) that I like to use with AL. It’s faster than the other two, and it does the work without all the meaningless tokens for “You’re absolutely right!”. It, however, doesn’t handle picture input. Less relevant for AL, but worth keeping in mind.

Still remember that if you don’t have any of these models available in your model selector, you (or your organization admin) have to enable them in GitHub Settings.

And if you’re of the exploratory type when it comes to models, you absolutely have to give Stefano Demiliani a follow. He tests each new model with AL and reports his impression on all social media. I only touch models that he approves. :P

MCP Servers

Lastly, let’s talk about the MCP servers. They’ve been all around the news for a few months now, but I think we’re right at the brink of getting a “perfect bouquet of MCPs” to use for AL development.

Before I jump into my current recommendations, I want to provide a short explanation of what an MCP server is. I’ll use the same analogy I used in the recent session for our partner.

Everyone understands the concept of VSC extensions. We have this vanilla development environment that allows us to write code. Still, if we want to add any additional functionalities to it (like support for AL), we need to install extensions for it.

But an extension that’s built for VSC will not work for Visual Studio or JetBrains.

The same story applies to Copilot and other AI-assisted development tools. Remember that the true power of the GitHub Copilot Agent mode comes from its tools:

But if we create an additional tool for GitHub Copilot, it won’t work with tools like Claude Code, Codex, Aider, and others.

And that’s what MCP (Model Context Protocol) is here to solve. If we build our Copilot extension in a way that it’s MCP-compliant, then any tool that supports MCP can make use of our additional tools.

Regardless of whether the tools are added through an extension or through an MCP server, their behaviour remains the same. It’s just a protocol of how the tools “plug in” to the client.

A lot of people have used the “USB-C” analogy in the past, and it does fit. Let’s say you have a printer that plugs into your PC via USB-C. The “logic” is in the printer, not in the USB-C connector. The connector is just a connector. But it allows us to plug the printer into anything that has a USB-C hole. The same applies to MCPs. The logic is in the “extension”; MCP ensures that we can plug our logic into anything that has an MCP hole. :D

Okay, so what MCPs should you try out for AL development?

GitHub / Azure DevOps – depending on what you use for issue tracking, these are an obvious choice. It enables the agent to read and update tasks, as well as handle pipelines. Very useful.
Microsoft Docs – I’ve had several tasks where the agent surprised me with “let me search the documentation”, found the BC related articles, and continued with much better context.

These are the easy-to-install MCPs that you can find by opening the MCP library from VSC.

A worthwhile non-MCP recommendation is something you might already have in your toolbox: NAB AL Tools. Johannes added Copilot tools to his already existing extension, and if you’re working with translations, the following blog is a MUST READ.

But back to MCPs, the following ones will need a bit more manual work, but everything is explained in the readme files:

Al-symbols-mcp - Created by Stefan Maron, it allows the agent to look into the dependencies for additional context. Usually, when working on an app, the agent can only see the code from the workspace. This MCP adds tools that can give it access to objects that are in the .alpackages folder. It’s brilliant for PTE apps where most of the context is in the dependencies—more information in the ReadMe file in the repo.
Bc-code-intelligence-mcp - This one is from Jeremy Vyska, another must-follow person if you’re into the Copilot story. It’s hard to believe Jeremy was in the “autocomplete” camp 6 months ago, because he has already done so much to push the Copilot story further for AL devs! Anyway, this MCP brings A TON of AL dev guidelines to your agent so it writes code as it should be written. It’s hard to explain everything this MCP does, so it’s best if you check Jeremy’s recent blog post.

The last MCP recommendations are a bit more experimental. I have not spent enough time with them, but I have a strong feeling they’re going to be very instrumental in the future:

Serena - By default, the agent navigates through your codebase using text search. Serena enables it to do semantic retrieval, navigate through the codebase on the symbol level, and exploit relational structure. Usually, these advanced tools would be reserved for “mature” languages like Python, C#, or JavaScript, but thanks to the “madman” named Torben Leth, they have just received a PR with AL support. I use madman in a very complimentary tone. :D Torben is one of those people who gets involved in projects that I’d consider impossible (like bringing BC to Linux).

He also just published the MCP for the AL Object ID Ninja made by Vjeko. Finally, agents will know which ID to propose, but I have yet to test this one out: al-objid-mcp-server.

Warning: Don’t go crazy installing all the MCPs you can find. Every added tool will eat away at the context window of an agent, and there will be less space for context about your project or the goal. Stefano described it perfectly in his recent blog post.

VS Code will warn you if you’re trying to fit more than 128 tools in your prompt, but even 128 is already a huge number.

Azure DevOps MCP alone comes with 70 new tools, and do you really need to have all the actions related to pipelines enabled when your usual workflow consists of reading and maybe updating work items? I think not.

Was this too long? Nah, I had to put all the current ideas into vol.2. I already know there’s going to be a vol. 3 soon. The next area worth mentioning is going to be the background agents, the ones we no longer oversee. I also think we’ll see many more MCPs in the next few months, until they all consolidate into an AL Extension Pack equivalent of MCP servers. I think it’s also time to revisit the topic of code review, this time through an AI-assisted lens.

Let me know your thoughts on any of the social media, and see you on the next post!

100 Areopa Webinars Visualized

Sun, 02 Feb 2025 09:00:00 +0100

Areopa Webinars just hit number 100! And I used this milestone as another visualization side-project. :P

If you don’t know Areopa, the short description of it is a YouTube channel of BC-related webinars that have been going strong most Mondays since 2019! Luc van Vugt leads it, but the whole community contributed to the content! Luc, if you’re reading this, you really do deserve a shoutout… You didn’t only create this huge (and still growing) collection of BC knowledge, but you’ve also setup a platform where anyone can come and share what they know with everyone!

Here’s why I care so much about Areopa. I’ve been very lucky to be in a position, where I get to travel to multiple conferences every year, and I listen to so many amazing sessions. It’s easy to stay “up to date” when I hear about best practices all the time, directly from the industry’s best. But not everyone gets that chance. And here’s where Areopa really excels, it brings that same level of high-quality sessions to everyone! For free! Forever! Conference sessions are great, but we forget most of what we hear the very next day. Areopa makes it available forever. You can always get back to a certain topic once it’s relevant to you again.

I didn’t want to just give praise to Areopa though. As I mentioned at the beginning, I used this opportunity as another visualization side project. Back in November, after Ignite, I came across this visualization by Nitya Narasimhan.

She grouped all Ignite sessions into groups and visualized them. I was so amazed with the concept that I knew I needed to find some time to play around with Markmap. My initial idea was (and still is) to make a similar visualization for all sessions at Directions EMEA, so I can have an easier time deciding what I’d like to listen to. I mean, it’s super hard to keep track of ~200 sessions otherwise…

I’ve started being more involved with Areopa within the past few months. Finding speakers, moderating webinars, and presenting my own topics, and as we were approaching this triple-digit number, I realized I have no clue about half the videos available on the channel. I was thinking about how could we make this huge collection of videos more discoverable. You can already see how this turned into a perfect opportunity to play with Markmap. Below you’ll find the result. I invite you to explore the graph, and if any video sparks your interest, go ahead and watch it! :P

But just before I let you go, I wanted to share a few “fun facts” that I found as I was handling the data of the videos:

First video’s publish date: Jul 7, 2019
Total number of unique speakers: 64

Top 5 most frequent presenters:

Luc van Vugt – 13 webinars
Tobias Fenster – 8 webinars
Arend-Jan Kauffmann – 6 webinars
waldo – 6 webinars
Dmitry Katson – 5 webinars

Top 5 most watched webinars:

Most common topics:

Test Automation: 16 videos
AL: 12 videos
DevOps: 12 videos
Functional: 12 videos
Power Platform: 7 videos

Interested in what’s under these topics? Well then I won’t keep you waiting any longer, here’s the visualization. You can zoom in and out, move the graph around, and click on the nodes to expand or collapse them. Click around, explore!

Copilot is just a fancy autocomplete...

Fri, 03 Jan 2025 09:00:00 +0100

December was a very Copilot month for me. After seeing some glimpses of new capabilities at Directions and more later at Ignite, I decided to spend some time trying out the “new” features of GitHub Copilot in Visual Studio Code. They’re not really new; they’ve been around for a while. I just never used them, as I thought they were not useful for AL development.

Boy was I wrong…

Copilot is no longer just a fancy autocomplete… it has become much more!

I didn’t want to get my hopes up too much with AL, so I started testing everything out with more mature languages like C# and TypeScript, but the more I tried the new features with AL, the more I was convinced that I needed to start sharing that autocomplete is no longer the only useful part of Copilot!

They’ve now also introduced a free tier for GitHub Copilot. This means everyone can now “just try it”, without any commitments!

For everyone who’s going to try Copilot out, or has been using it for a while, I wanted to share a few very concrete examples of how I’ve been using features like Inline Chat, Copilot Edits, and Copilot Chat for AL (and a few for other languages), that will hopefully move you to explore more than just the “tab, tab, tab” behavior of AI.

Auto-complete

I really won’t spend much time here, this is the first use-case you’ve noticed, and it feels most natural. Do you see a grey suggested code you like? A tab and it’s yours 😉

I use this all the time, from procedure declaration, and adding fields, to commenting code

If you didn’t write quality ToolTips so far, then don’t expect quality ToolTips from Copilot

Yeah, yeah, it’s not a meaningful comment, but you get the idea.

One very important note to keep in mind is how Copilot knows what to suggest. It looks at your open files and takes up to 4 files as context. If you’ve got more than 4 opened, it tries to do its best to take something, which is not always the most appropriate file. So, if you want to have better Copilot suggestions, close the unrelated tabs and only keep the relevant ones open.

I was used to having tens of files opened, so I needed to get used to right-clicking the tabs a lot and closing anything that was no longer relevant.

The autocomplete is something you’ll discover immediately, and even this feature alone saves enough time to fully justify the 20$ price tag of the Pro version.

The most interesting thing about autocomplete though? It’s what’s coming to it next! Awesome feature, can’t wait for it to be released.

Anyway, let’s move on.

Copilot edits

In my opinion, this is the game changer! This is the feature that turns coding into a conversation. A very brief description of it is a chatbot, that won’t only suggest you a code snippet that you should paste somewhere but goes in and modifies your files.

I first used it with a C# project, and I was blown away! I was working on some old code I wrote a year ago, and I asked Copilot to apply best practices. Within a few seconds my code was much more readable, had safe typecasting, used HashSets instead of Lists, and was just generally better code than I would ever write on my own. Devs that work with C# daily would still run circles around me as I “craft” my prompts, but I made much better progress than I could without it.

Later I started playing with some TypeScript. I have very little knowledge of TypeScript, and it would probably take me days to learn the basics of React on top. But within a few hours, I was able to make an Azure DevOps extension in TypeScript that allows me to visualize Page Scripting yaml files directly in DevOps. It was such a fun journey. More on that in a separate post one day! :P

Okay, okay, Tine, everything works great with C# and TypeScript, we’re here for AL, does it work with AL?

It does! And wonderfully so!

Of course, not to the extent that it works with C#. You won’t get any meaningful best practices applied in AL. We still have the same issue of “There’s not enough AL data to train these models”. But here are two very important parts that make Copilot Edits work so well for AL.

First, you can select a different LLM model to power the code generation. Autocomplete is powered by GPT-4o, which is “meh” for AL, but in Copilot Edits, you can switch between models.

Claude 3.5 Sonnet is so much better when it comes to AL. Why? I have no clue. But it just is. So, if you’re going to play with Edits (or Chat and Inline) for AL, switch to Claude immediately!

Note: If you don’t see Claude, you have to enable it in your GitHub settings (or if you’re getting your license through an organization, the organization admin has to enable it for you).

A better model is just part of the story though. The second part is “limited scope”. I mentioned in the auto-complete part that it will look at up to 4 open files and try to give you a good suggestion. Well, with Edits you are in complete control of the context that the model receives.

You add files you’d like the model to consider to the working set. Either by dragging and dropping them or by clicking “add files”. Once you have files in the working set, those are the only files that the model will focus on.

Okay, enough theory, let me show you how I’ve used Edits for some AL workloads.

A bit of a backstory.

We were recently working with Wair, a partner that has a backend service for AI inventory predictions. They wanted to make life easier for ISVs and VARs in the world of BC who would want to integrate a BC solution with their backend system.

Usually, each partner would have to develop logic that authenticates against the backend, builds the HTTP request, and then sends the request in the correct format. To make life easier we built a library app that introduces a set of temporary tables that match the HTTP request payload, and a set of codeunits that turn these tables into JSON payloads and send the request to the correct endpoint. That way, the BC partner needs to insert a record in the table and call a procedure with that table. That’s it.

You can imagine that when the backend introduces a new endpoint, we want to add new tables and codeunits to support it.

So, I tried if I could add a table with Edits that would follow all the conventions we have in other tables.

In this case, Brand is the new endpoint I want to support. I create a new Brand.Table.al file (I’ve noticed Copilot sometimes struggles with creating files, so I prefer to create them on my own and let Copilot fill them in), and pull it in the working set. I added one of the existing tables, so Copilot knows how I want to have it structured, and here comes the prompt:

Create a Brand table with brand ID, code, and description. It should follow the structure of the Category table.

Seconds later

Everything on the left side was just generated. Of course, it struggles with Object IDs. No one likes object IDs. Not even Copilot! :D

But you can see that in seconds I have a table with the namespace, properties that we use, and even a check for non-empty code.

You could say “Yeah, but that’s a simple example”. Fair, but I’d argue the easy and boring parts are the best ones to automate. Yes, you could copy-paste the other table and change a few things until it fits your new use case, but a) you’re bound to miss something, b) you’ll still be slower, and c) wouldn’t you rather spend your time on something else? Who wants to work on boring stuff anyway?

I suggest you always finish the Edits session when you’re done with those files and open a new one. LLM models operate on a limited context window, and even though we hear about context windows in the millions of tokens, anything above ~8k tokens starts to give diminishing results, so it’s best to start a new session every time.

Anyway, let me continue with the example of what else I “made in seconds”. We now have the table for our new endpoint. We need a codeunit that will transform the content of this table into a JSON payload and call the appropriate endpoint.

I’ll again create an empty file where I want my codeunit for handling the Brand API to be created:

This time, I’m pulling in my empty file, my existing codeunit, and the table we just created, so Copilot knows what properties are available for brands. The prompt is straightforward

And a second later, boom, a codeunit that builds the payload and sends the request

The important part here is that I passed a similar implementation as part of the context. Out of curiosity, I tried a similar prompt without including the Category API Handler. I was still pleasantly surprised by the result:

It doesn’t follow the structure I need for this project, but it knows how HTTP requests are built and sent in AL. This would still be a cool start if I needed to build my first handler that I could later spread across other tables.

Okay, tables? Check. Codeunits? Check. Pages? Eh, trust me, it works, I don’t want to make more screenshots. What about tests? Same principle. Do you have similar tests? Then yes. Look:

These tests worked because the overall structure was very similar between the existing objects and the new ones. But testing can really become a breeze. Vjeko had an awesome session on it at Directions, and hopefully, he’ll do an extended version at BC Tech Days. He’s been preaching Interfaces as a way of truly testing your code in isolation for a few years now, and with Copilot, most of those tests can now be generated.

But here’s the catch. You have to use interfaces in your code. Your procedures have to have a single responsibility. Your files have to be small. To get the most out of AI, your code should be SOLID. But you should be following SOLID principles for your own sake anyway, so take this as another nudge towards spending more time on writing SOLID code if you haven’t started already.

I know not everything is a greenfield project and you sometimes have to deal with big codeunits. Here are two prompts that I’ve used on legacy code with Edits

Move global procedures to local
It analyses all the global variables and moves them to procedures if they’re not used anywhere else.
Extract procedure X to codeunit Y
Unlike a simple extraction, it will also add a codeunit variable in the local scope and replace the call with the codeunit’s procedure call.

Both will still start to take too long if your files go beyond 500 LoC, so please, for the sake of AI, keep your files small :P

Even in perfect conditions, Copilot may sometimes take long or even get stuck. It happens, it’s best to accept it, stop the execution, discard the changes, and try again:

This section is getting long; we have to move on. But I really am excited about this feature, it brings so much joy to me when I get to blitz through code. Coding is the boring part, it’s the problem-solving that’s the fun part. That’s also why I don’t believe AI is replacing devs, it’s just helping with the boring parts…

Let’s take a look at more incremental edits next.

Inline Chat

This one was available for a while, but I never really found a use case for it that I’d like. Well, now I have a couple, so let me give you some ideas.

Add comments

I’m right now working on a legacy project. Large files, not much new is created, it’s about maintaining the existing code. In the days of NAV, we didn’t have the internal access modifier, so everything was either public or global. The problem with global is that you can’t change a thing, as it’s a breaking change, so on this project, we decided to make all procedures internal. If a procedure needs to be public, it should have XML documentation.

So, you start with three slashes to get the docs snippet

You accept it, but then you see this: 😮

Well, that’s going to be boring… The names are self-explanatory, but we agreed on what we agreed, and I have to fill in all the parameters. If I try to autocomplete this, I’ll tab for a while…

Ctrl + i to the rescue!

You could also select the whole procedure and prompt with “/doc”, but I found this way to give me better results.

Am I super proud of this comment? No, but hey, legacy has better fires we can fight. :D

Subscribing to events is something very common for an AL developer. Here’s how I’d go about before Copilot. Let’s say I’m extending Sales-Post. I’d first find the event I like:

Next, in my subscriber codeunit, I’d use the eventsub snippet:

Start filling out all the parameters…

Go back to the Sales-Post codeunit and copy the event name…

Remove element name, think for a second about skipping the event on missing permissions or license, but then just put false, because hey, I always put false…

Go back to Sales-Post and copy the signature of the event publisher…

And now finally, I can add my logic.

I mean, it’s not the slowest process in the world, but here’s my new alternative.

I still find the event publisher, but I immediately copy the event signature, go to my codeunit, press Ctrl + i and ask for a subscriber

Seconds later…

This is now my preferred way!

Add fields

I mentioned earlier that Edits start to break down on large files. I try to keep them sub-300 LoC. But that’s not always an option, so Inline Chat helps in those cases. I use it for adding multiple fields:

Perfect? No. Faster? Yup.

A few more prompts that I occasionally use

Forward slash
a very lazy way to switch all the pasted paths from backslashes to forward slashes as I’d otherwise have to escape them in JSON files 😅
Add label for regex that matches 123-1414-2124-223
Quickly get regex patterns that match the validations I’m looking for

Chat

This one I admit I don’t use as much for AL, but it’s quite useful for other languages. You can probably tell that I love Copilot Edits. But Edits want to implement something too quickly. Like that junior developer that wants to code before I’m halfway through my sentence…

That’s when I turn to chat as a starting point. I discuss what I want to do, and when I’m happy with the suggested code, I pass that suggestion to Edits so it gets added.

Edits will take the conversation as context and will apply the changes in the necessary files. Chat is a nice “safeguard” when I’m not completely sure how I want to solve the problem.

It’s also useful when the file is too big for Edits (> 500 Loc), as I can always copy-paste the suggested snippet into the correct place.

A few final nuggets

Here are a few more tiny notes that can help you make the most out of GitHub Copilot:

Commit message

Generate commit messages for staged changes.

Rename

Renaming suggestions for just about everything that can be renamed

Different models

If you’re only working with AL, stick to Claude. If you’re working with other languages, here’s how I see and choose models

Claude: Great for generating new code, but gets “drunk” quickly if there’s too much context and starts suggesting weird things
o1: Great for reviewing existing code. It takes longer and there’s a rate limit after which you have to wait for some time before using o1 again
GPT 4o: fastest responses but seems to shoot from the hip a lot. Less accurate results with complex requests.
o1-mini: Somewhere between o1 and GPT 4o, It’s faster than o1, and better at reviewing code than GPT 4o. I usually use it when I hit the rate limit of o1.
Gemini 1.5: No idea yet, I’m still waiting for it to be released

Free vs Pro Tier

The free tier right now gives you

Access to Claude 3.5 Sonnet models
2000 Code completions per month
50 chats per month (edits and chat count towards the same limit)

In my opinion, that’s enough for you to test these features out if they work for you. But as I mentioned at the beginning, even the autocomplete brings enough value to AL developers that it’s worth the 20$ for a Pro license.

Pro has unlimited completions and chats (except the o1 rate limit)

Quick Recap

Copilot Edits – Best for large-scale code changes, refactoring, and generating new files.
Inline Chat – Great for small additions, comments, and repetitive edits.
Copilot Chat – A fallback when edits feel too aggressive or when brainstorming solutions.
Autocomplete – The most familiar feature – saves time with quick code suggestions (worth the Pro tier alone).
Model Tip – Use Claude 3.5 Sonnet for AL work; it handles AL better than GPT-4o.
Scope Control – Keep files small and focus Copilot on relevant files for better suggestions.

Final remarks

This was a very long post. But that’s because there’s so much to say about this awesome tool that we have. I honestly believe it’s the next big thing. Then again, I’ve been an enthusiast for a while :P

Anyway, I’m playing with the idea of going deeper into this topic at some conferences this year. Share more examples, show more pitfalls, and explain more of the under-the-hood parts. What do you think? I’d love to know your opinion. You can let me know on LinkedIn, BlueSky, or X!

Trigger Sequence in AL

Wed, 01 Jan 2025 09:00:00 +0100

Here’s a small “let me bookmark this” post.

I often did not completely understand trigger and event sequences in AL. I sort of knew them, but I doubted myself just enough to keep going back to the documentation. It’s not like the documentation is bad, but every time it took me just a few additional minutes to figure out the answer, that I decided I wanted to visualize this.

It came in handy for me, maybe it will for you too. I’d love to hear if you’d add any other sequence!

Few things to remember that I didn’t want to jam into the visualizations

Apps with lower IDs execute their triggers and subscribers before those with higher IDs.
For example, if App A has an ID like “1bs3..” and App B has “c23f..”, App A’s triggers and subscribers will always run first.
Within the same App, objects with lower Object IDs execute their triggers and subscribers before those with higher Object IDs
A subscriber in Codeunit 50000 will execute before one in Codeunit 50001. Similarly, triggers in Table Extension 50000 will run before those in Table Extension 50001.
Subscribers in the same codeunit are executed in alphabetical order by procedure name
For instance, a procedure named MySubscriber1 will run before MySubscriber2, regardless of their order in the code.

When looking at the Lookup flow, remember that only one OnLookup trigger can be executed at a time. Once the first one is executed, others are ignored.

I made a small trigger logger for the purpose of this post, you can find it here. It’s a simple extension that logs the trigger and event sequence to a table.

Trigger Flow Diagrams

Record Operation Triggers:

Field Operation Triggers:

flowchart TD Start --> NoChart NoChart(Click a button to display trigger flow)

Forget how; when should we use preprocessing symbols?

Sun, 06 Oct 2024 10:00:00 +0200

This was one of the most difficult blog posts to write so far. I kept changing directions of what I even wanted to explain with it…

You see, I come up with blog ideas by explaining concepts to colleagues internally, and when a topic comes up often enough, I write it down as it’s easier to share with everyone. The other aspect is when I see a concept “in the wild” which gets me thinking about how we should adopt it internally, and to structure my thoughts, I write it down, making it easier to defend my position.

The topic of preprocessing directives comes mainly from this second part. The way Companial is positioned, I get to work with many different partners every year. Sometimes I learn from them, sometimes I can suggest best practices that I’ve seen elsewhere. In my opinion, it’s a win-win.

I recently started working with a partner that has a huge solution. I mean HUGE! 20k+ objects. That’s a crazy amount of code. It was also my first time using preprocessing directives, which made me wonder why I had never needed them before.

Here’s why:

I was building apps from scratch, that no one had a dependency on yet
It means I didn’t have to worry about breaking changes or the obsoletion process
We targeted SaaS tenants only
There was no need to support multiple versions of codebases in parallel
The work items were never too big
We never had big long-lived branches that would cause merge conflicts

The above three bullet points took me quite a while to realize, but once I wrapped my head around it, it was finally clear to me when I’d want to use the preprocessing symbols and that’s what I want to share with you today.

I’m not going to talk too much about how they work, Yun had a great blog post on that topic, back when they were introduced. Another great post I found was by Natalie. She describes how we should test code with conditional directives very well. But I’ll focus mainly on when is a good idea to use them for our apps.

Introduce changes gradually (announce changes)

We’re now in the AppSource era. Anyone can potentially depend on the apps we publish there. We cannot just remove a public procedure from our app, as that might break any app that is using it.

Hold on, aren’t obsoletion tags and App Source Cop there to prevent that? Yes! However, these tools only prevent hard-breaking changes. Changes that would prevent an external party from even compiling their app against our new release. However, they do nothing when it comes to soft-breaking changes.

Soft-breaking changes?

Changes that won’t prevent an external party from compiling their app, but their apps will no longer work as expected.

Take the removal of a field for example.

Let’s look at the “IC Partner G/L Acc. No.” That will be removed from Gen. Journal Line

We know we can’t just remove a field. App Source Cop will be all up in our faces if we try that. So, we obsolete it first, and we’ll remove it in one of the subsequent releases.

But no cop would yell at us for removing the field’s trigger, on any of its references… Imagine if this is how we obsoleted the field:

We removed the trigger, and we removed the references, but hey, we marked the field as obsolete. We’re gradually introducing changes…

Yeah, no. We still broke everyone using this field, immediately after this update is deployed.

So, what’s the better way?

Wrap the changes in preprocessing symbols and clean them in a later release. Here’s how MS actually obsoleted this field.

It means that today, the field still works exactly as it did for years. But anyone using it in their apps will get a warning that they should move away from it. When the time comes, they will enable the CLEAN22 symbol, the field becomes removed, and the code is no longer executed.

This becomes especially important if we want to refactor events. Let’s look at the following change.

App Source Cop is fine with this change. We’ve obsoleted an event. The next release can remove it. However, since the event is no longer being fired, any changes from event subscribers are now ignored. All external apps that were using this event are now broken.

If we want to introduce changes gradually, this should be the way to go:

Today, the event still fires off. Any subscribers are warned that the event is going away and that they should find a different solution. When it’s time, we can enable and clean up the preprocessing symbols to apply our change.

Does that mean I should wrap every change I make in preprocessing symbols?

Every change breaks someone’s workflow

But that doesn’t mean we should be afraid to make changes. Preprocessing everything is a sure way to maintenance hell.

What I want to point out is that if we have a code path that many external apps extend or use we should think about gradually introducing changes in that code path, and preprocessing symbols are the way to go about it. Especially when dealing with events.

Support multiple versions

OnPrem isn’t dead. And when supporting OnPrem customers, we usually have to support more than one target version of BC. Supporting them through a branch-per-version approach the symbols are less relevant to you, but if you have a single codebase, here’s why you should consider using them.

Don’t wait until the last second to make changes

When Base App obsoletes a functionality or an event, should you fix it immediately? Or wait until it becomes an error? Waiting until it becomes an error is a big no-no in my book. I believe in the no-warnings approach. I know it’s not as easy for old legacy codebases, but new development should have zero warnings. Period.

In v24, No. Series procedures became obsolete due to the move to the Business Foundation. I had a couple of apps where I had to fix these warnings. I didn’t have to do that. Old code will still work until (at least) v26. But I’d just be pushing work down the road. It’s understandable, if there’s a higher priority right now. But if we have the time, why take that additional tech debt on?

What if I’d still have to support v23 as well? That means I cannot just fix all warnings…

Well, I can, with preprocessing symbols:

When I build higher versions, I enable the symbol, and the warnings are gone. When I drop support for v23, I can clean up the v24OrGreater symbol, and I’m done.

This point applies even more if we’re building a new feature. If we build a new feature and decide to use the old NoSeriesManagement codeunit, we’re willingly throwing even more work on the tech debt pile.

Quick side note, this nice line highlighting showing me which line is active and which obsolete is provided by AZ AL Dev Tools, so if you’re working with preprocessing symbols, the extension is a must-have.

Merge changes early

Out of the three reasons for using the preprocessing symbols, this is the one I used the least, but at the same time, I’m also most interested in it.

This summer I held a session at Tech Days about Code Review where I was trying to be quite dogmatic about keeping pull requests small. Long-lived feature branches are a recipe for issues; constant merges, merge conflicts, and very painful code reviews. And yet a few months later, I find myself working on long-lived branches and huge pull requests. It was easy to “preach” small pull requests when we were only building new features. Now we’re dealing with refactoring a huge monolith.

I’m changing “just” one field and have to touch more than 150 other objects. Crazy. But I get it, changes have to be made on an all-or-nothing basis.

But that got me thinking, why is that? Why do they have to be made on an all-or-nothing basis? Can we get around that somehow?

I talked with friends who work in other languages about how they would deal with this issue. At first, it seemed they didn’t quite get my problem. They just said “feature flags” to everything I said…

Okay, feature flags. Hide the functionality behind a flag and merge to the main branch. But what about the table fields that I have to add? I can’t “hide” the additional fields on a table behind a feature flag, and if I just add them and make a mistake, I won’t be able to remove them, as it would be a breaking change…

And that’s when it hit me. What if I use preprocessing symbols as feature flags? This would solve my problems. Merge smaller chunks of changes to the main branch quicker, and once everything is in and tested, turn it on and clean it up!

As I said, I’ve only started exploring the feasibility of this approach as an alternative to long-lived branches and big PRs. But I do like how it looks…

Okay, this should give you an idea when using symbols can be a good idea. Before I wrap this long post up, here are a few more quick questions I sometimes get from developers:

When should we clean up the symbols?

Clean them up immediately after you turn them on for a production release. Seriously. I guarantee you, that you’ll never enable a symbol, build, test, and release the app, and then realize, oops, we need to undo those changes. If we need an option to “undo” the behavior, run-time feature flags are a much better option.

The only exception to this rule is the preprocessing symbols used to support multiple versions, like our v24OrGreater example above. Clean those up as soon as they’re enabled for all versions you support. In our case, that would mean when we drop the support for v23.

How do I clean them up?

I have a small script that you can find here. It loops through all files in the project and removes the code paths for a specified feature flag. There are likely other tools already out there, that can handle the cleanup. Preprocessing symbols aren’t exactly a novelty, even in AL they’ve been around for a while.

How do I enable a Symbol for the Base App?

I got this question quite a couple of times, and I remember I too was confused in the beginning when I didn’t understand preprocessing symbols. You open a base app object like Sales-Post and see a CLEAN23 code path. How do I “enable” this new code path?

You don’t.

Microsoft does. And when they will, you won’t see those symbols anymore, as they’ll also clean them up. Think of those code paths as “what’s going to change in the future”, but is currently not in use. As we talked about, it’s mainly about Microsoft introducing changes gradually.

Finally

Do preprocessing symbols make the code less readable? Yes, yes, they do. Do they make testing harder, as there are now more possible code paths? Another resounding yes. All these coding decisions always come with trade-offs. Should you use them? I don’t know. I made this post, to make my reasoning about it easier. But it doesn’t mean that they will apply to your situation. At least next time you have issues like these, you know that preprocessing symbols can be a way to deal with them.

Namespaces in AL - Is it time to start using them?

Sun, 01 Sep 2024 10:00:00 +0200

School’s back, so it’s time for the blogs to get back! This time I want to take a jab at namespaces. Not really the technical “how” of namespaces. I believe that part is rather easy and has already been covered multiple times. Microsoft presented a brilliant session about namespaces at BCTechDays this year. Instead I want to focus on WHY. That’s a question I recently received multiple times. We never needed namespaces in the past, why do we need them now? Do they bring any benefits or are they just a hassle? Is it time to start using them?

Over the past few months, I got to work on apps that were namespaced, apps that weren’t, and completely greenfield apps where I could decide if we wanted to adopt namespaces or not. So, this post is a view on namespaces from my perspective, and feel free to disagree with me.

Why Namespaces?

Structure

I often do “audits” of large code bases for partners, trying to determine the extent of their tech debt, whether they will ever get to multi-app architecture, or reach AppSource compatibility. To be able to do that, I need to understand the app’s architecture, what am I even looking at.

When I have to work with large apps where the src folder looks like this:

I take a deep breath, ask myself 7 times why am I doing this to myself, and then try to make sense of files that are supposedly important, and work my way through their references. It’s never a fun experience.

On the other hand, if I open a project and the project is separated into areas like this:

It makes a huge difference. I can wrap my head around individual parts that logically fit together. Structuring your code in functional areas does wonders for discoverability. Shocker, right? Any new developer you try to onboard onto your codebase will have to go through the same process I have to go through, and high discoverability makes this process much smoother. If I can’t convince you that the second folder structure is better than the first one, that I probably won’t ever get you to uptake namespaces…

Fine Tine, organized code is better than not organized, what do namespaces have to do with that?

Well, structuring your code in folders per functional area is in my opinion a prerequisite for starting with namespaces. Discoverability is something legacy codebases lack the most. Not surprising, considering we used to just work with a long list of objects sorted by type and ID.

Let’s say I open a file like this:

Where does this Enum belong? Who knows… I have to go through the references to figure that out.

But if it has a namespace defined:

Then I can quickly see it’s part of the Stock APIs functionality. And you’re right, if I only care about the code discoverability, then I could just look at the folder structure where the Document Type file is placed and get the same idea, I don’t need namespaces for that.

But structuring your codebase and making it discoverable is just one of the benefits of namespaces, while it’s the only benefit if you use folders as the only method. That’s why we should do both. Organize code in folders and use namespaces. It makes the project easily discoverable, but also unlocks other benefits of namespaces like dependency analysis.

Dependency Analysis

Let’s talk about dependency analysis next. This one has been huge for me lately. It allows us to ensure that cleanly architected apps remain clean. It also helped with de-tangling functionalities in monolithic apps and breaking down those horrible “Management” codeunits.

I’ll assume you already know that when we start adopting namespaces we move from a global namespace, where we could define any object as a variable, to a specific namespace, where we can only define objects defined in the same namespace, fully qualify object names, or “import” objects from other namespaces using a “using” statement.

In other words, we used to be able to do this:

With namespaces, we can’t:

Unless we do one of the two:

Before we get back to dependency analysis, let’s talk about which of the two options we should go for. Fully qualified name, or the using statement.

We decided to always go with using statements in favor of fully qualified names. Why? Because it allows us to easily see dependencies at the top of the file (this is the dependency analysis that we’ll get to in a second). We haven’t found a real use case when we’d prefer to go for fully qualifying names. In the C# world, I’d go for fully qualified names if I’m using two objects that have the same name but reside in different namespaces. However, in AL:

We’re quite used to making globally unique object names
As of now, can’t define an object with the same name in the same app, regardless of namespaces

Back to the dependency analysis now. We now know that anytime we want to define a variable for an object from a different namespace, we have to use a “using” statement. This means that from a quick look, we can see what other modules our object is tied to.

Here’s how a Sales Header table looks once Microsoft applied the namespace to it:

I couldn’t even capture all of them in one screenshot. There are 76 of them. Crazy. Also, a bit ugly. But at the same time a good thing! At least now Microsoft has a high-level overview of all the parts that are jammed in the Sales Header table and can start working towards extracting irrelevant parts.

By irrelevant I don’t mean that the functionality is irrelevant. But does the Sales Header have to be coupled to Dataverse? Or Outlook? Doesn’t it feel a bit off? Removing Dataverse functionality shouldn’t break sales documents. I’m not trying to diss Microsoft’s code. The base app is old, and there’s a lot of legacy code in there. Here’s how the relationships in the Base App look like today:

To be honest, we all wrote entangled code like that in the past. But what I’m trying to say is that with namespaces we can now finally start spotting these spider webs. Both in our old code and when writing new code. Does the latest pull request try to add two new “using” statements to a management codeunit? Are we creating another Swiss army knife codeunit? Maybe we should separate them and stick to a single responsibility.

Naming

Naming is a very common reason why we’d want to use namespaces in other languages. As we only ever had a global namespace in AL (and C/AL), all of our objects had to have globally unique names. That’s why we had a “Sales Header” and a “Purchase Header”. If we were in the world of C#, these would likely be Microsoft.Sales.Document.Header and Microsoft.Purchase.Document.Header

Two “Header” objects, but since they reside in separate namespaces, it’s not a naming collision.

Unfortunately, we’re not there yet with AL. Defining two objects with the same name in different namespaces in the same app produces an error.

Which is weird to me, since what I can do is define an object with the same name as an object in a different app. Like creating my own Customer table in my own namespace:

So, namespaces prevent naming collisions, but not in the same app?… Hopefully, this will work in the future…

The one naming benefit we however do have is that we don’t have to try and jam long names in only 30 characters.

Here’s an example from one of the projects: “MYPETaxFSTBlock”
Any idea what this is? Yeah, me neither. ETax and Block I get, but what’s FST?

Well, if we had namespaces at the time, this file would likely be

Namespace MyPublisher.Banking.ETax.Declaration
Codeunit 50000 “MYPFormStructureTypeBlock”

By moving the area that this objects belongs to out of the file name, we free up the 30 characters for actual name of the file. This again makes the codebase more onboarding friendly.

The how of namespaces

I said I won’t go into the “how” of namespaces, but I want to mention a couple more technical good-to-knows about namespaces

How should I structure namespaces?

Here’s what we’re using. Again, only a recommendation and a guideline, deviate from it as much as you’d like.

<Publisher>.<AppArea>.FolderStructure

Example: Companial.Banking.Setup

Important! We don’t (and won’t) register namespaces with MS (like we register affixes), so make sure yours are unique.

The first part should be your publisher’s name to ensure the namespace is unique from other partners.
The second part is the App area. Not the App name mind you. We try to find a more generic name. Mainly, so that if we’d ever move an object to a different extension, we don’t end up with an object that has a very app specific namespace and would “stick out”. This point is very applicable to monoliths that we’ll want to break down into smaller apps.
The third part is then the folder structure. The actual path of the file. This ensures files are easily discoverable by following the namespace.

For comparison, here’s Microsoft’s recommendation:

Whatever you do, please don’t just add one namespace to every object in your project. Unless your project has less than 25 objects, I believe you have multiple areas hiding in there.

How to ensure I don’t forget to add namespaces?

There’s a CodeCop warning (AA0247) we can use to help us spot missing namespaces. It’s disabled by default, so we have to raise it’s severity in the ruleset.json

When should I not adopt namespaces?

If you’re app has a dependency on another app that has not yet adopted namespaces. Do not add namespaces to your objects in these cases as your app will break once the dependency adopts them. Let me quickly show you why:

Here’s the happy path:

App A depends on App B. No namespaces are used. Everything works.

Dependency (App B) introduces a namespace. No issues in App A, as we’re still using the global namespace

App A now introduces namespaces and at the same time has to add a using statement for the dependency codeunit and can compile against the new version of the App B:

Now the unhappy path:

App A is the first to define a namespace and everything works since the Dependency is still in the global namespace:

But now when App B adds a namespace, App A is broken and cannot work with the new version of App B

The problem is, that you don’t know when your dependencies will adopt namespaces, so I’d personally avoid them until all dependencies are namespaces.

In all other cases, I’d say go for it!

Is adding a namespace a breaking change?

No. Yes, we’ve seen how it can break dependencies, but it’s not a breaking change in the sense of the AppSource validation. You can add namespaces to your objects and still pass the validation.

Where can I learn more about namespaces?

The recording of Microsoft’s session is a must-watch if you’d like to see how they approached the challenge of namespacing the whole base app.

Here’s a few common questions they answered in the session:

And of course, the official documentation is always a good place to start.

So, is it time to use namespaces and should I now go and namespace my huge monolithic app?

Is it time to use namespaces? Absolutely. Small apps, new apps, greenfield apps, all should start using namespaces. They bring a lot of benefits, and I believe they’re a step towards a cleaner codebase.

But should you go and refactor your huge monolithic app to use namespaces?

Probably not. I mean, yes, there are benefits to using namespaces, but if you have a huge project, it will take you a long time to properly segregate objects into namespaces areas. Unless you have enough time to do it properly, I’d postpone it. Again, adding a single namespace across the whole project is not a good idea.

Conferences are awesome! Here's a quick recap...

Wed, 10 Jul 2024 10:00:00 +0200

I’m about to go off on a longer vacation, but there’s one more post I wanted to make before I go offline. I was partially inspired by Natalie’s non-technical post right after BC Tech Days about her experience there, and I wanted to do the same, but for the full spring conference swing.

I was lucky enough to participate in 6 (six!) events in the past 4 months. Days of Knowledge (DOK) UK, DOK Nordic, Directions NA, Dynamics Minds, DOK Central, and BC Tech Days. I loved every second of them. But even for this “youngling”, that was a lot of traveling, and I’m taking a more relaxed approach to summer.

I was thinking a bit about how I wanted to structure this post. I want to present the events if you may not yet know them, and don’t know if you (or your employees) should attend them. And I also want to share my takeaways from each of them. Now these takeaways might be completely random and highly personal, but to me, that’s the best part about these in-person events. You get to talk to people and at some point, you might hear some highly interesting views!

Days of Knowledge Tour

Days of Knowledge is a set of events organized by the same amazing people that bring us Directions EMEA (and Asia) every year. However, unlike Directions, these events are entirely focused on upskilling people. There are three tracks of sessions running in parallel. Developer, consultant, and Power Platform track. I’ve been speaking at three events this year; UK, Nordics (Denmark), and Central (Germany), but there’s another one happening in the US (Atlanta) in September, and you can still register for it here.

I love the concept! Bringing deeper knowledge (plenty of level 300 or 400 sessions) than what you’d get at Directions, and for a lower price. I wish there were even more events in the upcoming years, so more people could experience it. But as we’ve already noticed this year, with the growing number of events in the BC sphere, it’s taking a toll on speakers, as they have to travel quite a lot.

My take is that there’s no better event for consultants than Days of Knowledge. But also for developers, who want to understand more of the functional and Power Platform side. I think more often should developers try and understand the functional side, it makes us better. Here we can, with a dedicated track for non-development sessions. I’m not saying that developer sessions are not great, but the functional track is why you should consider sending developers to other events than simply Tech Days.

Some interesting things I’ve heard or seen at DOK events that made me go “huh”:

Being natively fluent in English can be a huge boost in how your session turns out
Most AL developers are not technical (by education)
It’s hard to present details if people don’t know the basics
This one was interestingly controversial. Don’t be passionate about AL. AL is a language that pays our bills. If you want to be passionate about technology, find a side project where you can be creative.
Don’t run Power Automate flows on user accounts. You fire a guy, and half the integrations stop working.
The delivery of a topic is as (if not more) important as the content itself.

Here are some of the people that made these events fun!

Directions North America

I doubt Directions North America needs an introduction. It’s been around for a while. I also don’t have much of a recommendation of who should you send to these events. I’ll mainly share my “huh” moments, but before I get there, here are a couple of things I found…different, compared to Directions EMEA.

Look at these statistics they shared (disregard the yellow lines, those were for entertainment purposes):

When I saw these numbers, I was mainly surprised by two parts. The age of participants, and their role.

Two-thirds of the participants were over 40. I know there are probably a lot of actual reasons for that (it’s an expensive event, it’s a commercial event, …), but as someone who sees these conferences as the main reason why I decided to stay in this industry, I felt uneasy.

I want more younglings here! :D

Close to three-quarters of attendees were in Sales and Leadership positions. You could feel that in the sessions as well, they were less attended. I get that Europe has more of a “builder” mindset, while the US prefers to buy solutions, okay, fine. But still, where do your people then get upskilled if not at these kinds of events?

Some “huh” moments:

Copilots are everywhere. It’s not that long since it was introduced, and partners are already trailing regarding AI knowledge.
MS is hesitant to publicly announce what they’re doing, but when approached individually they’re happy to share the direction in which they’re going.

DynamicsMinds

This is probably the most “under the radar” event in the BC sphere. But it shouldn’t be. It’s a fairly small event (if you can call 1250 attendees small) in Portorož, Slovenia, aimed at the full D365 stack (FO, CE, PP, BC). It’s a brilliant event! Organization-wise, second to none. It’s hard to describe what makes it so amazing. The attention to detail, the creativity behind the keynote, the fact that MS only gets 5 minutes per product for their sales pitch during the keynote, the location, the food, … it’s probably just all of the above.

When I was sharing everything they did to ensure speakers had a good time, someone summed it up perfectly: “It’s not that you expect that they would do all these things for you, but they do them anyway”.

If you want to experience an event like no other, this is the place to go. But even though, I’m highly supportive of this event, there is something to consider when you’re deciding who should attend it.

If you have practices that work with FO, CE, or PP, stop thinking, and send them all. How many other events do you have that cater to FO? But if your focus is primarily BC, my recommendation is to send more architect or manager-level people. There’s so much you can learn from where other parts of D365 are evolving. But if you’re only looking for BC sessions, you might sometimes struggle with what to listen to. Especially if you’re used to BC events where you have multiple sessions specifically for BC in each time slot.

I’m super sure that this event will sell out next year, so if you’re interested, get your tickets early.

Some “huh” moments from this one:

There’s so much more to Power Platform than what we “the BC” people are aware of
PP has a hard time working with BC due to the “we can solve it in BC” mentality

BC TechDays

Another event that needs no introduction. The crown jewel if you’re a BC developer. BC Tech Days was the first conference I ever attended. Two years ago, I was that unsure developer, standing in the corner somewhere, not really knowing what to do during coffee breaks. Fast forward two years, and I couldn’t believe just how fast the event passed by. So many people to meet, so many people to talk to.

To me, this was also the most demanding event to prepare for. My sessions are usually 45 minutes long, this was the first time I did a 90-minute one, and boy did it take some prep time… It was all worth it.

One of the great things about BC TechDays is that all sessions are recorded, so if you’d like to check out what I was talking about, you can find it here. And you can find all the other recordings here.

The only “huh” moment I took from this one, which isn’t even that surprising, is:

This community and its people are awesome!

Okay, so now you know a little bit about the sessions you should attend next year. Here’s a quick recap of my take on the target audiences:

Days of Knowledge – Awesome event for upskilling consultants and especially Senior Developers wanting to broaden their functional or PP knowledge.
Directions NA – Sales & Leadership mainly, but there are a lot of cool sessions as well
DynamicsMinds – One-of-a-kind conference experience. Content is best suited for Architects, cross-product developers, D365 people, and Leadership
BC Tech Days – Developer’s favorite. BC Developers of all levels

This conference season was a blast for me. I already knew I loved sharing knowledge and doing sessions last year, but this year truly cemented it. I put a lot of effort into my sessions.

Before I ever started doing conference sessions, I talked with one of the greats in our industry about just how much time it takes them to prepare sessions. The answer was 50 - 100 hours depending on the session. That made me realize from the beginning that great content and great delivery take time, and I’m more than willing to put that time in. I delivered a total of 12 sessions at these events with an average speaker rating of 4.92/5 and a content rating of 4.76/5 out of roughly 200 ratings. I’m proud of these numbers. It means the time was well spent, the audience enjoyed it, and it all becomes worth it.

If you’re ever sitting in a conference session, I want you to leave a rating and a comment. If you liked it, the good comments stay with a speaker like a long-lasting applause. If you think there’s something to improve, comment as well. I believe my session at BC Tech Days turned out as well as it did mainly because I received constructive feedback on previous events. That’s how I knew what content the audience was missing, that I should interact with them more, and that everyone likes memes, and I should include more. :P

Okay, enough. Now you know what cool events are out there and you should definitely look out for them next year! Now, it’s time for me to pack and take some time off.

BC Online has new operational limits! Here's how to make the most out of them...

Wed, 24 Apr 2024 10:00:00 +0200

While in San Diego for Directions NA I attended a couple of sessions held by Sandy Winarko on new operational limits for Job and API limits in BC Online. I think it’s great that they’re working on making the cloud more appealing, but to make the most out of the new limits we have to change how we run jobs or integrate with BC. How? We’ll get to that in the second part, let’s first talk about what changed.

New schedule task limits

Let’s start with the scheduled tasks more commonly known as job queue entries. Previously, the maximum number of concurrent jobs that could run simultaneously was 3. That was a hard limit set per environment. Three concurrent jobs were not enough, especially if multiple companies needed to run scheduled jobs. They have now changed this limit from 3-per-environment to 5-per-user. This means that I can now schedule 10 jobs to run simultaneously, as long as 5 jobs are scheduled by User1 and 5 by User2.

This is an important detail. More users means more parallel jobs, but not if all jobs are scheduled by a single user. The limit is per user, so different users need to schedule jobs to make use of this higher limit, otherwise 5 jobs will be executed and others will wait.

Now this is annoying, especially since it’s not uncommon to have just one person responsible for scheduling jobs. However, we can take advantage of these new limits as they also apply to S2S users. Something I was playing around with is, that I registered multiple Entra Applications in BC, and created an action on the Job Queue Entry Card to schedule the job as a System user. More on that in the second part.

New OData request limits

Similarly, the OData limits also got a refresh from per-environment to per-user limits. Let’s first take a look at the old limits.

We could send up to 600 requests per minute (300 for sandbox environments), of which 5 were concurrently processed, the rest piled in a queue of up to 95. When the queue was full, 429 - Too Many Requests was returned.

First, the change in rate limits. It changed from 600 per minute to 6000 per 5 minutes. Meaning, we can now have higher peaks of requests as long as they’re not too close together.

The new concurrency limit is again per user. Say we have 5 users, we can have 25 OData requests processed concurrently if they’re coming in as 5 different users. This also means we have 5 queues where the requests will wait. But the same “important detail” applies here. Just because we have 5 users in our environment doesn’t mean we can process 25 parallel requests. They will only be processed in parallel if they come in as 5 different users.

I personally always built integrations with BC by creating an Entra App Registration and sending all the requests as this one user, but to make use of this additional throughput, I started looking into distributing the requests across multiple Entra Applications and thus benefiting from parallel processing. More on that in the second part.

You can read more about the new operational limits here.

But now let’s jump into how to make the most of the new limits. I would like to add that I’m not a fan of these session-hacking approaches. Should we really be doing this? Microsoft said yes, but honestly if they’re giving us additional capacity per user, why add this (maybe stupid) limitation that it also needs to be consumed per user? Is it really additional capacity per user, when we can create an unlimited amount of Entra Application users? I have a feeling this will change again soon, as this is more of a workaround than an architectural approach. But hey, sometimes workarounds are needed.

Schedule a Job as an S2S user

Okay, I can achieve higher throughput by scheduling jobs as different users. But scheduling jobs is my responsibility, I don’t want to go around asking people to schedule jobs for me…

To solve this, I started playing around with the functionality that would allow me to schedule a job as a system user, using one of the S2S application users. To get there, I created a couple of app registrations

I’ve added two new fields to the card, to specify if the application should be used for scheduling jobs and its client secret

Now I can go and create a new Job Queue Entry as I normally would. Once I set it up the way I want it, I have a new action to schedule the task as a System User:

Once the action is executed, the job is scheduled as one of the available Entra App users

Let’s take a look at what’s happening in the background when the action is executed.

A tl;dr is, the action finds an Entra App with the least number of scheduled jobs assigned to it and calls a BC API to schedule the selected job as this Entra App. But let’s still look at the code a bit.

The action calls this EnqueueJob procedure:

Check Web Service simply ensures that my API for enqueuing jobs is published

This is the API that will schedule the job

Find Least Loaded App finds the Entra Application with the least amount of Job Queue Entries assigned to it. Only Entra Applications that are set up for Job Queue scheduling are considered. Currently, it just looks over all the job queue entries. The next step would be to take the scheduled period into account. If the new job should be scheduled for Monday morning, then I’m only interested in Entra Apps that are least loaded on Monday morning.

I won’t get into the details of GetToken and SendRequest, one retrieves an AccessToken from Entra for the given app, and the other builds and sends a request to the above-mentioned API. If you’d like to see the full source for this example, you can find it here.

This approach now lets me take full advantage of new concurrency limits by simply adding more Entra Applications as needed and scheduling the jobs under these apps.

Integrate with BC Online using a S2S user pool

So we know how to make the most out of the new scheduled tasks concurrency limits. What about OData? Well, to make the most out of this one, we’ll have to change the way we authenticate our requests that go to BC. As mentioned earlier, in the past, we created an Entra App and used this app for all requests. Now, we should instead introduce an app pool, and distribute our requests across many Entra Apps. I built a simple example in C# to show how this can be used. You can find the full source code here.

Again, a quick tl;dr first. The program initializes a User Pool Manager with my Entra Applications, creates an Api Service using this pool manager, and then when calling the API, it will rotate the Entra applications used in authentication in a round-robin manner.

Keep in mind, that this is only a quick demo, so there are many shortcomings. Don’t hardcode secrets, don’t request a new token each time, as they’re valid for a longer period, … But I hope this example still illustrates how we can rotate S2S users for request authentication.

Here’s the Main class

S2SUser is just a simple class to contain credentials

UserPoolManager manages the pool of users and rotates them

ApiService is where we then actually call the API using a different user every time

Using this approach, I can now shoot calls off to BC and have 15 requests processed in parallel instead of the usual 5. If I’d need even more throughput, I’d create more Entra Apps, and spread the load across.

One final thing to keep in mind. At some point, Microsoft will introduce global limits or “quotas”, so this “free performance” won’t scale forever, but at this point, they haven’t yet decided on the quotas. Once they’re in place, the docs will be updated accordingly. But overall, It’s great seeing improvements on the infrastructure side of BC. I hope we’ll move away from having to abuse multiple sessions, but anyway, looking forward to what’s coming next.

Exploring the new Release Wave as a Department - The Blueprint

Mon, 15 Apr 2024 10:00:00 +0200

A new release is on the streets! Yay!

I like new stuff, it’s exciting. But a Release Wave every 6 months, even if it’s not the biggest wave, makes it difficult for us as a Business Central department to stay up to date.

Usually, it comes down to individuals taking their time to investigate what’s new, and maybe sharing with a couple of colleagues over a coffee. But that wasn’t the best approach, as not everyone took the time to look into the release notes, and even if we did, we usually focused on things that sounded interesting to us. That means, we know what the new topics in development are, but Power Platform? Governance? Reporting? Eh, not my area…

Turns out, the longer you ignore “not my area” topics, the more difficult it becomes to pick them up when a project rolls around that needs to leverage the Power Platform for example. This wasn’t the best approach, so for this release, we decided to take a more structured approach to how we’re going to stay on top of everything Microsoft released. And hence, here’s “The Blueprint” of how we went about it. Is it the best way? We don’t know yet. It worked out pretty okay this time, but we’ll know when future releases start rolling out.

The problems we wanted to solve:

How do we explore ALL the topics of a new release
How do we share the findings with the whole department
How do we ensure that knowledge is retained

Now we could go for Directions for Partners What’s new webinar or Companial’s overview of functional and technical enhancements. But as great of an overview as these two webinars provide, they still only scratch the surface, and as a department we don’t have any hands-on experience with the new topics. So we needed something more.

Here’s our approach

We built a team of 6 people, all experienced, but not only seniors, who were tasked with exploring the new release and we broke the release plan down into 6 topics, one for each:

Power Platform
Application, Country and Regional, Legislation
Copilot and AI innovation
Development
Governance and administration
Reporting and data analysis, user experiences

Some topics are bigger than others. We approached it in two ways. If an area was too big, someone with a smaller area took some of the topics. The alternative was, that the person with a smaller area went a release further back, to v23 in this case, and explored what was new there. As mentioned at the start, we weren’t exactly thorough with previous releases, so there are plenty of things to catch up on.

We decided to spend a day off-site to work on our exploration. Nothing fancy, just away from the office. There’s always an email or a bug waiting otherwise. We scheduled it during Microsoft’s Launch Event, primarily because one of the goals each person had was to come up with at least 3 questions to ask during the Q&A sessions. It’s how we ensured that each one has gone deep enough into the topic and also critically thought about it, what’s missing? What’s the future? What could be clearer?

During the day, the focus was mainly on launch event videos, documentation and hands-on demos. We had a couple of quick catch-ups to present our findings among ourselves and just brainstorm on potential questions we’d like to get answered. The only preparation we did beforehand was for everyone to set up their cloud sandboxes where we demoed the features.

After our exploration day had ended, we started preparing for a 90-minute Knowledge Sharing session for the whole department we held a week later. We wanted each one to have their time slot, instead of one person presenting everything. Partially so everyone could hone their presentation skills, but also so they become the go-to person for their area. Not like the go-to person, but just someone who others can now reach out to if they have a question in this area.

This worked out pretty well. We now have a department that is aware of new features and 6 people who have a deep understanding of new release areas. The plan for the next release is to rotate them and get 6 new people diving into the Release Wave 2. That way, we’ll slowly upskill more people into “off-brand” topics like governance or data analysis, and additionally, they’ll have people from the first Wave to discuss topics with.

Lessons learned

Things sound great so far, but here’s a couple of lessons learned that we’ll try to address next time:

Don’t expect that people will catch up on 4 years of release waves in 8 hours. Keep investigations contained.
People can get caught on a single topic for a full day. Time box and move on.
Ask very specific questions to Microsoft. “What’s the future of Copilot?” will get a vague response. They won’t commit to any future plans. But they’ll gladly clarify details of new features.
8 hours of research is draining. Remember to take breaks and keep things light.
Even a seemingly small release can easily occupy 6 people for a day.

I know “losing” 6 people for a day might be a big ask for some partners, but I believe it’s totally worth it. The tasks regarding tenant administration, or virtual tables will feel far less daunting, as we now have people who can support us on these non-traditional work items. Also, I can’t speak for the rest of the team, but I found diving into topics “beyond” BC quite exciting!