Home
Dynamics 365
Business Central
Troubleshooting Series – Ep4 – Event Recorder

Troubleshooting Series – Ep4 – Event Recorder

Next topic in this series: the Event Recorder. “This Series”, you might wonder? Yes: I’m doing (slowly but steady) a series on anything “troubleshooting tools” including “my own view” on the different topics. Here is an overview of what I already covered.

Next question could be: what on earth is “the Event Recorder”? Well, to be complete: Events discoverability – Business Central | Microsoft Learn. So in short:

It’s a functionality in Business Central ..

That has a “start/stop” button, with which you can record all events that has happened during a certain process.

What I do to record events:

So – just assume you’d like to know what events were happening during the post-process:

Open the Event Record
Open that page in another window ()
In the main window, navigate to the document you want to post.
Start the event recorder
Post the document

Stop the event recorder

You’ll get the message if you’d like to display the recorded events:

And there you have it:

A list of events, on order of execution, per type .. even with the ability to get the AL snippet to easily copy/paste the code to subscribe to the event in AL code.

Super handy for any developer searching for the right place in code to add their

Next – you might wonder: this is a troubleshooting series – what does a dev tool have to do with troubleshooting??

Well, quite honestly – it’s not like I’m using it daily for troubleshooting – not even weekly – but I HAVE been using it just to figure out behaviours of Business Central that I didn’t seem to understand. Remember: it’s right there where you need it: in the client! So let’s go over a few angles that I see it fit:

Performance

Just imagine you have a long running process that is caused by a long loop. By recording that process, the result might indicate you are calling the same event a ridiculous amount of times .. which helps you in troubleshooting performance.
Or may be simply to spot duplicate event triggers, or heavy subscribers, or to compare slow vs fast traces.. .

Functional troubleshooting

Or what about claims from the users (or consultants) that certain “validations” or other functions are simply not being executed. You can easily proof or figure out what validations ARE firing.. .

Debugging

It can even give you more insight on debugging customizations – because, you know – it displays the events of apps you own .. and even don’t own. And may be pinpoint so breakpoints or debug-code you might want to add during troubleshooting.

Alien Extensions

Yeah – it displays all extensions’ events, so it can definitely also help you in understanding how extensions that you don’t own act in certain processes.
Or did you ever come into the situation where you wondered if certain extension has conflicting behaviour because you wonder if certain extension subscribe differently to the same event? Of course we have .. well .. “easy” to identify with the event recorder!

Documentation

And last but not least I could come up with: what about the use in documentation and knowledge sharing: in a way, it’s a reproduction, a trace, .. steps that has been taken. Which in its own can be a source of “documenting what happens under the hood”. Who knows: if you let some kind of LLM on the loose, it could come up with some kind of nice description. What if we combine this with page scripting.. . I didn’t test this, but I can imagine it’s worth exploring .