Telemetry is not only about performance

Telemetry is not only about performance

If you hear about telemetry it is almost all about if Business Central had the right performance and how you can optimize your code with analyzing your telemetry (Lon Running Queries, Long Running AL methods etc.).

But there is also a functional part of the telemetry. You can see the Pageviews. In that way you can see which pages are used or with the user flow you can see how the users are navigating in Business Central.

Besides that there is now also “Feature Telemetry” (BCTech/samples/AppInsights/AL/FeatureTelemetry at master · microsoft/BCTech ( With Feature Telemetry it enables you if users are really using your great feature that you have build. And who don’t want that 😊.

If you want to implement the “Feature Telemetry” you must implement the codeunit “Telemetry Logger”:

If you don’t do this you get the following error in your telemetry:

Be aware that you implement only once for each publisher. Otherwise you get the following message in your telemetry:
“More than one telemetry logger has been registered for publisher ..”
The telemetry flows in that Application Insights!

There are three use cases for “Feature Telemetry”:


FeatureTelemetry.LogUptake(<tag>, <feature name>, <Feature Uptake Status> (enum));

With LogUptake you can closely watch if you feature has a uptake among the users. There are four states where your feature is in (you can set this with the enum “Feature Uptake Status”). In the examples I use the feature “Dataverse Sync UI” found here Bertverbeek4PS/DataverseSyncUI (

The state Discovered is if users has discovered the feature. Moslty you want to add this to the pages that are related to the feature on the OnOpenPage trigger (like a setup page or just a list page):

Set up

This state the user has successfully setup your feature. So the best place you can put this in the OnInsert trigger of your setup table:


Then a user is using your feature successfully without having an error then you must use the state Used.
You can add this state to actions in the ribbon or put is in a function that your feature is always using.

This state you want that never will be used 😊. With this state users disables your feature and don’t want to use it. So you can put this moslty on the OnDelete trigger of a setup table.


FeatureTelemetry.LogUsage(<tag>, <feature name>, <event name>);

With LogUsage you can measure if a feature is used or not. It is most the same as the state Used of LogUptake. But LogUsage you use when you don’t have an setup page etc. But only you have one action and that is your feature.
An example is you build a feature on the customer card that copies values to processing table. Then you can use the LogUsage function.


FeatureTelemetry.LogError(<tag>, <feature name>, <event name>,<Error Text>);

This function you use when there is an error raised in your feature.

Application Insights

When you have implemented it you can analyze your telemetry if your feature is used. With the following KSQL query you can analyze it:

| where timestamp > ago(30d) //adjust when needed
| where customDimensions.alFeatureName == "Dataverse UI"


You can also analyse your Feature Telemetry by using the Power BI app of Business Central Telemetry:

There is a section “Feature Usage”


You can also add your own dimensions to the feature telemetry!

All the samples you can find on the following Pull Request:

Feature Telemetry added by Bertverbeek4PS · Pull Request #19 · Bertverbeek4PS/DataverseSyncUI (

Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.