When Auditing meets Telemetry: a practical example.

This post is based on a real-life data auditing story, and where telemetry did the extra mile.

The question was:

“A Default Dimension record set has been deleted. Is it possible to know who, when and how they were deleted?”  

Telemetry can do A LOT of good things but unfortunately it was not meant to be used for pure AUDITING purposes.

Auditing strategy in Dynamics 365 Business Central is duly written officially here:

Auditing overview – Business Central | Microsoft Learn

To make it more understandable for cavemen and cavewomen, like me, there are 2 types of auditing:

1. Security Auditing
2. Data Auditing

And these are addressed by two different features / tools.

• Change Log.

Save data changes info and store them in the database. This is used mainly for Data Auditing but also for some Security auditing. Change log is a very old Dynamics NAV application feature. It has its thorns (e.g. create gigantic costly $$$ tables in the database – if a solid retention policy is not established and placed in action – and if not used with precautions it can be the cause of performance decrease in I/O operations). See more:

Auditing changes – Business Central | Microsoft Learn

• Microsoft Purview.

Implemented in Preview (purview in preview… that is quite fun) since Dynamics 365 Business Central 2024 Wave 2 (v25). It is used, as of today, for security auditing only. See more:

Auditing events in Microsoft Purview – Business Central | Microsoft Learn

Frankly, I believe that it could be possible to perform the same tasks that both features / tools do also with telemetry (and with less up to no thorns 😉) but – again – this is another story. I keep my mouth shut.

So, now, back to the original problem of the phantomatic Default Dimension deletion, the first answer was to check if change log was active on that specific table and against deletion events. Yes, it was.

All good. Case closed? NO.

Within change log, we could gather the User ID and the date it happened (3^rd September 2025, 10:19 AM CEST).

It was nice to poke the user, and she swear on her boyfriend’s head (poor guy…) that she did nothing on dimensions, she was working on purchase orders as usual.

And now we are back where we started and in front of the court, today, we have:

The User (and her boyfriend’s head) vs Change Log entries

We are now calling to testify telemetry.

With a simple query that scanned both traces and page views, we were able to determine the innocence of the user (and save her boyfriend from the guillotine).

let _endTime = datetime(2025-09-03T08:30:00Z);
let _entraTenantId = '<entraTenantId>';
let _environmentName = '<environmentName>';
let _startTime = datetime(2025-09-03T08:10:00Z);
let _userId = '<telemetryUserId>';
traces
| union pageViews
| where timestamp between (_startTime .. _endTime)
| where customDimensions.aadTenantId == _entraTenantId
| where customDimensions.environmentName == _environmentName
| where user_Id == _userId
| project timestamp
    , eventId = tostring(customDimensions.eventId)
    , message
    , name
    , stackTrace = tostring(customDimensions.alStackTrace)
    , customDimensions
| sort by timestamp asc 

But how could this have happened then?

Telemetry is on fire! And I am on fire too…

Do you see that little RT0018 Long Running AL Method?

FillData triggered a Delete on a Temporary record for the Entity table

And this triggered…. Guess what?

The same old story: just one line, and where you place it, makes a big difference. In this case, checking for a temporary record was too late in the code execution and even if record was temporary the real default dimension data were deleted. Gone with the wind.

The outcome?

Change Log was right. The action was performed by the user.

User was right. She did not know that performing that action (CalculateLines) would have deleted dimensions for that specific record.

We moved the check for temporary record as first line in the OnAfterDeleteEvent to mitigate the issue. Problem solved, finger snap.

As usual, telemetry can connect the dots and in less than 1 hour, everything was dissected, sorted out, explained and resolved.

On a side note. The developer that checked temporary record after (and not before) deleting dimensions has not been harmed (officially… still…).