OpenTelemetry in Azure Logic Apps (Standard and Hybrid)
Why OpenTelemetry? As modern applications become more distributed and complex, robust observability is no longer optional—it is essential. Organizations need a consistent way to understand how workflows are performing, trace failures, and optimize end-to-end execution. OpenTelemetry provides a unified, vendor-agnostic framework for collecting telemetry data—logs, metrics, and traces—across different services and infrastructure layers. It simplifies monitoring and makes it easier to integrate with a variety of observability backends such as Azure Monitor, Grafana Tempo, Jaeger, and others. For Logic Apps—especially when deployed in hybrid or on-premises scenarios—OpenTelemetry is a powerful addition that elevates diagnostic capabilities beyond the default Application Insights telemetry. What is OpenTelemetry? OpenTelemetry (OTel) is an open-source observability framework under the Cloud Native Computing Foundation (CNCF) that provides a unified standard for generating, collecting, and exporting telemetry data such as logs, metrics, and traces. By abstracting away vendor-specific instrumentation and enabling interoperability across various tools and platforms, OpenTelemetry empowers developers and operators to gain deep visibility into distributed systems—regardless of the underlying infrastructure or language stack. In the context of Azure Logic Apps, OpenTelemetry support enables standardized, traceable telemetry that can integrate seamlessly with a wide range of observability solutions. This helps teams monitor, troubleshoot, and optimize workflows with more precision and flexibility. How to Configure from Visual Studio Code? To configure OpenTelemetry for a Logic App (Standard) project from Visual Studio Code: Locate the host.json file in the root of your Logic App project. Enable OpenTelemetry by adding "telemetryMode": "OpenTelemetry" at the root level of the file. { "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "telemetryMode": "OpenTelemetry" } Define the following application settings in local.settings.json or within your CI/CD deployment pipeline: OTEL_EXPORTER_OTLP_ENDPOINT: The OTLP exporter endpoint URL where the telemetry data should be sent. OTEL_EXPORTER_OTLP_HEADERS (optional): A list of headers to apply to all outgoing data. This is commonly used to pass authentication keys or tokens to your observability backend. If your endpoint requires additional OpenTelemetry-related settings, include those in the application settings as well. Refer to the official OTLP Exporter Configuration documentation for details. How to Configure OpenTelemetry from Azure Portal? – Standard Logic Apps To enable OpenTelemetry support for a Standard Logic App hosted using either a Workflow Standard Plan or App Service Environment v3, follow the steps below: 1. Update the host.json File In the Azure portal, navigate to your Standard Logic App resource. In the left-hand menu, under Development Tools, select Advanced Tools > Go. This opens the Kudu console. In Kudu, from the Debug Console menu, select CMD, and navigate to: site > wwwroot Locate and open the host.json file in a text editor. Add the following configuration at the root level of the file to enable OpenTelemetry, then save and close the editor. { "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "telemetryMode": "OpenTelemetry" } 2. Configure App Settings for Telemetry Export Still within your Logic App resource, go to Settings > Environment Variables and select App settings. Add the following key-value pairs: App Setting Description OTEL_EXPORTER_OTLP_ENDPOINT The OTLP (OpenTelemetry Protocol) endpoint URL where telemetry data will be exported. For example: https://otel.your-observability-platform.com OTEL_EXPORTER_OTLP_HEADERS (Optional) Any custom headers required by your telemetry backend, such as an Authorization token (e.g., Authorization=Bearer <key>). Select Apply to save the configuration. How to Configure OpenTelemetry from Azure Portal? – Hybrid Logic Apps To enable OpenTelemetry support for a Standard Logic App using the Hybrid hosting option, follow the steps below. This configuration enables telemetry collection and export from an on-premises deployment, using environment variables and local file system access. 1. Modify host.json on the SMB Share On your on-premises file share (SMB), navigate to the root directory of your Logic App project. Locate the host.json file. Add the following configuration to enable OpenTelemetry and save the file. { "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "telemetryMode": "OpenTelemetry" } 2. Configure Environment Variables in Azure Portal Go to the Azure Portal and navigate to your Standard Logic App (Hybrid) resource. From the left-hand menu, select Settings > Containers, then click on Edit and deploy. In the Edit a container pane, select Environment variables, and then click Add to define the following: Name Source Value Description OTEL_EXPORTER_OTLP_ENDPOINT Manual <OTLP-endpoint-URL> The OTLP exporter endpoint URL where telemetry should be sent. Example: https://otel.yourbackend.com OTEL_EXPORTER_OTLP_HEADERS (Optional) Manual <OTLP-headers> Custom headers (e.g., Authorization=Bearer <token>) required by your observability backend. Once you've added all necessary settings, click Save. Example of Endpoint Configuration & How to Check Logs To export telemetry data using OpenTelemetry, configure the following environment variables in your Logic App’s application settings or container environment: Name Source Value Description OTEL_EXPORTER_OTLP_ENDPOINT Manual Entry https://otel.kloudmate.com:4318 The OTLP receiver endpoint for your observability backend. OTEL_EXPORTER_OTLP_HEADERS Manual Entry Authorization=<your-api-key> Used to authenticate requests to the telemetry backend. OTEL_EXPORTER_OTLP_PROTOCOL Manual Entry http/protobuf Protocol used for exporting telemetry (KloudMate supports gRPC/HTTP). In this example, we are using KloudMate as the destination for telemetry data. Once correctly configured, your Logic App will begin exporting telemetry data to KloudMate as shown below: Limitations and Troubleshooting Steps Current Limitations Supported trigger types for OpenTelemetry in Logic Apps are: HTTP Service Bus Event Hub Exporting metrics is not currently supported. Troubleshooting Steps No traces received: Validate OTEL_EXPORTER_OTLP_ENDPOINT URL and port availability. Ensure outbound traffic to observability backend is permitted. Authentication issues: Review and correct header values in OTEL_EXPORTER_OTLP_HEADERS. References Set up and view enhanced telemetry for Standard workflows - Azure Logic Apps | Microsoft LearnBusiness Process Tracking Reaches General Availability
Business Process Tracking provides key insights to business stakeholders from your Logic Apps (Standard) implementation in an efficient and timely manner. Today, we are pleased to announce the General Availability of this capability, allowing customers to leverage in their production workloads. In the following demo, we are updating a Business Process by creating stages and identifying key data properties that we want to track at a particular point in time. We will subsequently map our business process to a technical implementation. Once we have configured our business process we can deploy it to Azure. When the underlying Logic App workflows run, the key business data will be emitted to an Azure Data Explorer (ADX) instance where it can be visualized using our business process overlay. Support for CI/CD A key ask for customers has been support for Continuous Integration/Continuous Deployment (CI/CD). This capability enables customers to make their Business Process Tracking solution portable and allows you to deploy your business processes across your enterprise landscape. From a high-level perspective, you can think of the overall process to deploy business processes as: To simplify this experience, we have provided the following features: An Export button on your deployed Business Process that will allow you to download ARM templates and YAML pipelines that you can use in your CI/CD process. Updated the Logic Apps Standard Task in the Azure DevOps Marketplace that will integrate the underlying tracking profiles and app settings into the related Logic App(s). Product Documentation We have updated our product documentation to provide detailed steps on how you can implement Business Process Tracking CI/CD. Upcoming Roadmap We do have some upcoming plans on how we can expand the use of Business Process Tracking in the following ways: Codeful workflows Agent Loop Logic Apps HybridExporting Logic App Standard to VS Code
If you work on Standard logic app workflows using the Azure portal, you might find yourself wanting to use Visual Studio Code instead at some point. When you switch to Visual Studio Code and install the Azure Logic Apps (Standard) extension, you get the expanded benefits available only with the extension, for example: Better control over your development environment. Faster development experience with local debugging and testing. Integration with source control repositories. Automated parameterization for new and existing connections, which simplifies cross-environment deployment. Automated generation for deployment scripts, templates for Azure connectors, and deployment with CI/CD pipelines. Starting with the Logic Apps Standard extension 5.18.7, you will find a new way to create Logic Apps Standard workspaces from a package exported from Azure Portal. You can find the step-by-step process on our official documentation. Watch the video below to see how this feature works.Introducing Agent in a Day
Looking for a jumpstart on how to build Agents? Confused by the plethora of options when building Agents? You have come to the right place. In May 2025, the Logic Apps team introduced Agent Loop which provides the ability to build Autonomous or Conversational agents in Logic Apps. This gives customers an easy-to-use agent building design surface, the ability to deploy your agent to a Azure and integrate with Azure AI Foundry. Azure represents an enterprise-ready platform that addresses your organizational requirements including VNET integration, Private Endpoint support, Managed Identity and gives you several scaling options. Sounds great? It does, but how can I get started? This is where Logic Apps Agent in a Day comes in. We have recently published a step-by-step lab guide that will help you build an IT Support Agent that uses ServiceNow as the IT Service Management tool. The guide is available here: https://aka.ms/la-agent-in-a-day and we have included an Instructor Slide Deck in Module 1. Agent in a Day represents a fantastic opportunity for customers to participate in hackathon-style contests where attendees learn how to build agents and then can apply them to their unique business use cases. For Partners, Agent in a Day represents a great way to engage your customers by building agents with them and uncovering new use cases. Have any feedback or ideas on how to make this better? Feel free to send me a DM and we can discuss further.Codeful Workflows: A New Authoring Model for Logic Apps Standard
📝 This blog introduce early concepts of a pre-release functionality and is subject to change. Azure Logic Apps Standard offers you a powerful cloud orchestration engine, enabling you to build and run automated workflows that effortlessly integrate resources from various services, systems, apps, and data sources. Whether you're looking to streamline processes across a complex enterprise or simply reduce the need for extensive coding, this platform provides a solution that's both efficient and flexible. For those of you who require more control over workflow designs or want to leverage your expertise in frameworks like .NET and the Durable Tasks framework, Logic Apps Standard now introduces an exciting new feature: Codeful Workflows. With Codeful Workflows, you can define workflows using an imperative programming style, blending the flexibility of coding with the simplicity and operational strengths of Logic Apps. This means you can structure your workflows the way that makes sense to you while still tapping into the rich ecosystem of connectors and tools built into Logic Apps. What Are Codeful Workflows? Codeful Workflows expand the authoring and execution models of a Logic Apps Standard, offering developers the ability to implement, test and run workflows using an imperative programming model both locally and in the cloud. Built on frameworks like .NET and the Durable Tasks framework, Codeful Workflows allow you to structure workflows in code while seamlessly integrating with Logic Apps Standard rich connector ecosystem, and leverage its operational capabilities. The core elements of a Logic App workflow—triggers, actions and connections —are translated into durable task concepts within this codeful model: Triggers are implemented as Client Functions that invoke durable orchestrations, which contain the body of the workflow, blending logic implemented by the language primitives, with connections actions for external connectivity. Connector actions are presented as Activity Functions. The Logic Apps Connector ecosystem is exposed to you via an SDK, bringing discoverability and rich support for intelisense when creating action inputs, invoking actions or reusing action outputs in later steps. The SDK vastly simplifies the execution of those connectors, by wrapping them internally on a Activity Function, so you don’t need to create new activities for each connector action you want to invoke. Connections, which manages the connectivitiy between actions and end systems, remains unchanged, allowing you to setup once and share connections between multiple orchestrations and logic apps declarative workflows. Connector actions uses a reference to a connection, providing flexibility between local and cloud configurations. Using those building blocks, you can create workflows using familiar programming paradigms, while still benefiting from the easy configuration and operational feature of Logic Apps Standard. If you are an existing Logic Apps Standard customer, your codeful and visual workflows can coexist within the same application, bridging the gap between pro-code and low-code approaches. With those two execution models working hand in hand on the same application, Logic Apps Standard becomes a comprehensive orchestration tool that caters to all developer personas, from integration specialists to enterprise teams, with no cliffs on their experience. Creating Codeful Workflows Designing codeful workflows begins with creating a new Logic Apps project within Visual Studio Code, configured for .NET and the Durable Tasks framework. From triggers to actions, developers gain full flexibility to define their workflows programmatically. Implementing Triggers Triggers are the entry points of workflows, and in Codeful Workflows, they are defined as Client Functions. For example, an HTTP trigger can start a workflow when a request is received: [FunctionName("HelloTrigger")] public static async Task<HttpResponseMessage> HttpStart( [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestMessage req, [DurableClient] IDurableOrchestrationClient starter, ILogger log) { var requestContent = await req.Content.ReadAsStringAsync(); var workflowInput = new HTTPHelloInput { Greeting = $"Hello from Codeful workflows. You said '{requestContent}'" }; log.LogInformation("Workflow Input = '{workflowInput}'.", JsonSerializer.Serialize(workflowInput)); string instanceId = await starter.StartNewAsync("HelloOrchestrator", workflowInput); log.LogInformation("Started orchestration with ID = '{instanceId}'.", instanceId); return await starter.WaitForCompletionOrCreateCheckStatusResponseAsync(req, instanceId); } Using Connector Actions Both Managed and Service Provider Actions are available to be used within your orchestrations. They are organized in the SDK by type making it easy to find the right connector to use. Once you identify the action to use, you can use the rich intelisense interface to generate inputs and call the action directly in your orchestration code. Deployment and Operations Deploying Logic Apps Standard that uses both codeful and codeless workflows follows the same practices already available in Logic Apps Standard. Operational insights, such as endpoint visibility and execution monitoring, are provided within the Azure Portal, ensuring parity with the functionality available for codeless workflows. This cohesive deployment model allows organizations to maximize their resources and cater to diverse development needs, whether they require quick prototyping via low-code tools or robust, scalable solutions through pro-code implementations. Codeful Workflows and Intelligent Agents You can take advantage of codeful workflows and Logic Apps Standard Agent Loop to create new intelligent applications that embed advanced AI decision-making directly into your processes – enabling your apps and automation to not just follow predefined steps, but to reason, adapt, and act autonomously towards goals. See this demo where we share two approaches to implement agent loops – combining codeful and codeless workflows, where you can reuse existing workflows as tools, and writing agent loop actions directly with code: Looking for feedback on Codeful Workflows We are looking for early feedback on this feature. If you are interested in participating on a private preview, please use the form below to register your interest and we will contact you to share the instructions. https://aka.ms/lacodeful/privatepreview/formAutomatic Regeneration of Azure Managed Connectors Connection keys in VS Code Extension
Starting with version 4.57.6, the Azure Logic Apps (Standard) extension for Visual Studio Code will automatically regenerate the connection keys required to allow the extension to access Azure Managed Connections.IBM MQ Built-in (In-App) connector and Queue Handles: The math behind Queue Handles
In some scenarios, we found that it might be challenging to understand how IBM MQ server needs to be configured to be able to poll without experiencing the dreaded IBM MQ returned Reason Code: 2017 - MQRC_HANDLE_NOT_AVAILABLE.
