// article
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.
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.
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.
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.
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."
Application Insights stores Business Central telemetry in Azure Monitor tables that can be analyzed with Kusto Query Language. Create saved queries for:
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.
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.
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.
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.