AL Telemetry with Azure Application Insights: An Operations-First Guide

Telemetry is the operating contract for a Business Central extension. Tests explain what should happen in a controlled environment; telemetry explains what is happening across real environments, versions, companies, and workloads.

Business Central supports environment-level telemetry and app/extension-level telemetry. Both can send signals to Azure Application Insights. Extension telemetry is especially useful for publishers and partners because it can reveal failures and performance problems before a user provides a complete reproduction.

Connect the right Application Insights resource

For an extension, Microsoft documents the applicationInsightsConnectionString setting in app.json. The older instrumentation-key setting applies only to older runtimes and should not be the starting point for a new app.

// app.json
{
  "applicationInsightsConnectionString": "InstrumentationKey=...;IngestionEndpoint=..."
}

Do not commit a production connection string to a public repository. Treat deployment configuration and secret access as part of the release process. Confirm the selected Azure region, retention, access roles, and cost controls with the organization that owns the telemetry.

Use platform signals before inventing custom ones

Business Central already emits telemetry for many operations, including extension lifecycle, errors, long-running AL methods, SQL activity, web-service calls, reports, job queues, permissions, and Marketplace validation. Start by mapping those signals to the support questions you need to answer.

Add feature telemetry when the platform cannot describe the business event. Microsoft points AL developers to the Feature Telemetry codeunit in the System Application or the logging APIs for custom messages. A custom event should have a stable event ID, a clear purpose, and a small set of documented dimensions.

Design dimensions for diagnosis

Useful dimensions often include app version, operation, result category, feature, execution mode, and a non-sensitive correlation ID. Avoid sending names, email addresses, document descriptions, free-form error content, access tokens, or business values unless a documented privacy review explicitly permits it.

Record categories rather than uncontrolled text. For example, result=validation_failed is easier to aggregate and safer than logging a complete document or exception payload.

Measure a complete operation

A good operation has a start, outcome, duration, and correlation. If work crosses Business Central, a queue, and an external service, carry a correlation value through each layer without using a customer identifier. This lets support distinguish "Business Central did not create the outbound message" from "the receiving service rejected it."

Build queries around support decisions

Application Insights stores Business Central telemetry in Azure Monitor tables that can be analyzed with Kusto Query Language. Create saved queries for:

• failure rate by app version and operation;
• slow operations by percentile, not only average;
• new error categories after a deployment;
• web-service throttling and transient failures;
• extension upgrade and installation failures;
• environments still running a version that needs attention.

A dashboard should lead to an action. If nobody knows what threshold requires intervention or who owns it, the chart is decoration rather than monitoring.

Alert on symptoms that matter

Microsoft documents alerting options through Azure Application Insights, Logic Apps, and Power Automate. Avoid an alert for every individual error. Alert on sustained failure rate, a critical operation disappearing, a new error category, repeated upgrade failure, or a material latency change. Route alerts to an owner with a runbook and enough context to investigate.

Control cost and retention

Application Insights billing depends on ingestion and retention. High-cardinality dimensions and verbose success events can add cost without improving decisions. Sample or aggregate routine signals where appropriate, preserve errors and critical audit events according to policy, and review unused telemetry periodically.

Telemetry definition of done

1. The app and environment resources are intentionally selected.
2. Every custom event has an owner, documented dimensions, and data classification.
3. No credential or unnecessary personal/business content is emitted.
4. Saved KQL queries answer the top support questions.
5. Alerts have thresholds, routing, and runbooks.
6. Dashboards separate app versions and deployment windows.
7. Ingestion cost and retention are reviewed.

Review the telemetry design after each release wave and major integration change. New platform behavior, background jobs, or external dependencies can change which signals are useful and which alert thresholds create noise.

Bitta Apps combines AL extension engineering, integration observability, and Business Central support operations so telemetry leads to faster diagnosis instead of another unattended dashboard.