Plugins play a key role within many IT solutions built on top of Microsoft Power Platform.
Plugin can encapsulate business logic, enforce rules, and enable integration with APIs, external services, and cloud components — making it a critical part of an IT solution.
Just like any other component with an IT solution, plugins need telemetry tracking. Telemetry helps engineering teams diagnose issues, understand execution flow, and maintain visibility across the entire system.
In the Microsoft ecosystem, Azure Monitor — particularly its Application Insights feature — is commonly used to collect and analyze telemetry data. However, integrating Power Platform plugin with Application Insights is not straightforward.
This article explains how to implement telemetry tracking for Power Platform plugins with Application Insights.
Why the Built-In Mechanism Is Not Good
Microsoft Power Platform promotes using the ILogger interface combined with automatic data export to an instance of Application Insights.
Several key limitations make this approach insufficient:
- Limited Functionality — The ILogger interface introduces an abstraction layer over Application Insights, concealing much of its advanced functionality.
- Delayed Telemetry Delivery — Exported telemetry may take up to 24 hours to appear, significantly delaying issue detection and resolution.
- No Authentication Support — The export mechanism does not support authentication for accessing the Application Insights instance.
- Lack of Granularity — There is no way to isolate specific plugin telemetry.
- No Multi-Instance Publishing — Telemetry cannot be routed to multiple Application Insights instances.
In short, the built-in mechanism in the Power Platform is both technically constrained and operationally limited.
Direct Integration Is the Way to Go
Within the Power Platform plugin, the most efficient way to work with telemetry is to directly integrate with Application Insights using a dedicated client library.
That was the exact initial reason why the Azure.Monitor.Telemetry library was created — to provide an efficient way to integrate with Application Insights.
The library is lightweight, high-performance, and built specifically to operate under the constraints imposed by the Power Platform plugin runtime. It avoids all the pitfalls of Microsoft libraries while giving you full control over the telemetry pipeline.
If you’re curious why the standard Microsoft libraries are not suitable for Power Platform plugins, I encourage you to read this article, where I explain in detail the journey behind building the library and the critical problems it solves.
Azure Monitor Telemetry Client — Reinvented
You can find a fully functional sample that demonstrates how to use the library for Power Platform plugin development here: Samples on GitHub.
Things to Consider While Using the Library
Before using telemetry within a Power Platform plugin via Azure.Monitor.Telemetry, there are several important considerations that will influence how you structure the integration and manage configuration.
1. How Many Application Insights Instances Are Needed?
Decide how many instances of Application Insights the telemetry client will publish to, and where those instances will be located. There are typically two common scenarios:
- Single Instance (Organization Only): All telemetry is sent to an Application Insights instance managed by the organization.
- Dual Instance (Customer + Vendor): Telemetry is published to both a customer-managed instance and a developer-controlled instance. This gives development teams access to diagnostics without requiring customer-side access.
The Azure.Monitor.Telemetry library provides a TelemetryClient class that can be configured to use one or many instances of the HttpTelemetryPublisher class, each configured to publish telemetry to a different Application Insights instance.
2. Will Authentication Be Used?
Decide whether the plugin will use Entra-based authentication when sending telemetry.
Power Platform supports this through Power Platform Managed Identity (not to be confused with Azure Managed Identity), which can be used to securely authorize access to Application Insights.
The HttpTelemetryPublisher class can be initialized either without authorization or with a Bearer token obtained from Entra.
At the time of writing, Power Platform does not support assigning or switching between multiple managed identities within a single plugin. As a result, if dual-publishing is required only one can be authorized.
3. Where Will Configuration Be Stored?
Each telemetry publisher must be configured with two values:
- Ingestion Endpoint (URI)
- Instrumentation Key (GUID)
A recommended approach is to store the configuration as a JSON-formatted object in a single environment variable of text type.
4. What Information to Include in Each Telemetry Item?
The Application Insights data model provides many attributes that can be used to enrich telemetry data with contextual information. The library provides a TelemetryTags class to support this. Key attributes to consider:
- CloudRole — A unique name of the component. Use the alias or name of your plugin, or simply “Power Platform”.
- CloudRoleInstance — A unique identifier of the runtime environment. Use Environment.MachineName.
- OperationId — A unique identifier for the operation. Use IExecutionContext.CorrelationId.
- OperationName — A human-readable name for the operation. Use IExecutionContext.MessageName.
- ParentOperationId — A unique ID of the parent operation. Use IExecutionContext.OperationId.
- AuthenticatedUserId — A consistent user identifier across the Entra-connected systems. Use IPluginExecutionContext2.InitiatingUserAzureActiveDirectoryObjectId when applicable.
Careful configuration and proper enrichment ensure telemetry is actionable and easy to interpret — both for debugging and continuous observability.
Demonstration
One of the most important questions is: What does this telemetry actually look like in practice, and what insights can I get from it?
This demonstration walks through a practical setup and shows exactly what you can expect to see in Application Insights when using the Azure.Monitor.Telemetry library in a real Power Platform plugin.
Scenario Setup
The example solution consists of the following components:
- A Power Platform plugin (ProxyPlugin) that is triggered by an event on a Dataverse table
- The plugin publishes a message to an Azure Storage Queue
- A backend service (ProxyService) picks up the message, processes it, and deletes it from the Azure Storage Queue
- Both the plugin and the backend service are integrated with Application Insights using the Azure.Monitor.Telemetry library
This setup allows tracking the full flow of operations end-to-end, across both systems.
Application Map View
The Application Map in Azure Monitor is automatically built from telemetry data. It visually shows the interaction between system components.
In this setup, you see:
- ProxyPlugin sends message to Azure Storage Queue
- ProxyService receives message from the Azure Storage Queue
- ProxyService deletes message from the Azure Storage Queue
This high-level visualization makes it easy to confirm that telemetry flows correctly and relationships between components are captured.
End-to-End Transaction View
One of the most powerful capabilities of Application Insights is distributed tracing — the ability to follow an execution path across multiple components.
In this demonstration, distributed tracing lets you follow a message as it:
- Is sent by the ProxyPlugin
- Is recieved up by the ProxyService
- Is deleted by the ProxyService
Each of these steps is captured as a distinct telemetry item, all linked together using a shared OperationId. This correlation creates a single, coherent timeline of the entire operation, which you can visualize and inspect in Azure Monitor.
This view is essential for understanding how components interact, measuring timing between operations, diagnosing performance issues, and verifying that the system behaves as expected.
Plugin Tracing
If you open the built-in Power Platform Plugin Trace Logs, you can correlate trace messages with the telemetry seen in Azure Monitor.
This gives development teams confidence that telemetry reflects actual plugin execution and improves their ability to debug logic or timing issues.
You may match information with data available with Azure Montior.
This demonstration proves that a well-configured telemetry strategy gives you complete observability across plugin code and external services — all from within Azure Monitor.
Conclusion
Power Platform plugins are mission-critical components in modern business applications, and their behavior must be observable and measurable to ensure reliability.
Unfortunately, the built-in telemetry options provided by Microsoft fall short when it comes to flexibility, precision, and real-time diagnostics.
The Azure.Monitor.Telemetry library offers a focused and production-grade alternative that enables direct integration with Azure Monitor, supports multiple Application Insights instances, and honors the execution constraints of Power Platform.
By following the guidance in this article, you can:
- Track telemetry with full control and context
- Improve diagnostic capabilities and system transparency
- Empower development teams with real-time insights
Observability is no longer optional — it’s a requirement. And with the right tooling, it’s also achievable within Power Platform plugins.
Top comments (0)