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.
Moving the Logic Apps Designer Forward
Today, we're excited to announce a major redesign of the Azure Logic Apps designer experience, now entering Public Preview for Standard workflows. While these improvements are currently Standard-only, our vision is to quickly extend them across all Logic Apps surfaces and SKUs. ⚠️ Important: As this is a Public Preview release, we recommend using these features for development and testing workflows rather than production workloads. We're actively stabilizing the experience based on your feedback. This Is Just the Beginning This is not us declaring victory and moving on. This is Phase I of a multi-phase journey, and I'm committed to sharing our progress through regular blog posts as we continue iterating. More importantly, we want to hear from you. Your feedback drives these improvements, and it will continue to shape what comes next. This redesign comes from listening to you—our customers—watching how you actually work, and adapting the designer to better fit your workflows. We've seen the pain points, heard the frustrations, and we're addressing them systematically. Our Roadmap: Three Phases Phase I: Perfecting the Development Loop (What we're releasing today) We're focused on making it cleaner and faster to edit your workflow, test it, and see the results. The development loop should feel effortless, not cumbersome. Phase II: Reimagining the Canvas Next, we'll rethink how the canvas works—introducing new shortcuts and workflows that make modifications easier and more intuitive. Phase III: Unified Experiences Across All Surfaces We'll ensure VS Code, Consumption, and Standard all deliver similarly powerful flows, regardless of where you're working. Beyond these phases, we have several standalone improvements planned: a better search experience, streamlined connection creation and management, and removing unnecessary overhead when creating new workflows. We're also tackling fundamental questions that shouldn't be barriers: What do stateful and stateless mean? Why can't you switch between them? Why do you have to decide upfront if something is an agent? You shouldn't. We're working toward making these decisions dynamic—something you can change directly in the designer as you build, not rigid choices you're locked into at creation time. We want to make it easier to add agentic capabilities to any workflow, whenever you need them. What's New in Phase I Let me walk you through what we're shipping at Ignite. Faster Onboarding: Get to Building Sooner We're removing friction from the very beginning. When you create a new workflow, you'll get to the designer before having to choose stateful, stateless, or agentic. Eventually, we want to eliminate that upfront choice entirely—making it a decision you can defer until after your workflow is created. This one still needs a bit more work, but it's coming soon. One View to Rule Them All We've removed the side panel. Workflows now exist in a single, unified view with all the tooling you need. No more context switching. You can easily hop between run history, code view, or visual editor, and change your settings inline—all without leaving your workflow. Draft Mode: Auto-Save Without the Risk Here's one of our biggest changes: draft mode with auto-save. We know the best practice is to edit locally in VS Code, store workflows in GitHub, and deploy properly to keep editing separate from production. But we also know that's not always possible or practical for everyone. It sucks to get your workflow into the perfect state, then lose everything if something goes wrong before you hit save. Now your workflow auto-saves every 10 seconds in draft mode. If you refresh the window, you're right back where you were—but your changes aren't live in production. There's now a separate Publish action that promotes your draft to production. This means you can work, test your workflow against the draft using the designer tools, verify everything works, and then publish to production—even when editing directly on the resource. Another benefit: draft saves won't restart your app. Your app keeps running. Restarts only happen when you publish. Smarter, Faster Search We've reorganized how browsing works—no more getting dropped into an endless list of connectors. You now get proper guidance as you explore and can search directly for what you need. Even better, we're moving search to the backend in the coming weeks, which will eliminate the need to download information about thousands of connectors upfront and deliver instant results. Our goal: no search should ever feel slow. Document Your Workflows with Notes You can now add sticky notes anywhere in your workflow. Drop a post-it note, add markdown (yes, even YouTube videos), and document your logic right on the canvas. We have plans to improve this with node anchoring and better stability features, but for now, you can visualize and explain your workflows more clearly than ever. Unified Monitoring and Run History Making the development loop smoother means keeping everything in one place. Your run history now lives on the same page as your designer. Switch between runs without waiting for full blade reloads. We've also added the ability to view both draft and published runs—a powerful feature that lets you test and validate your changes before they go live. We know there's a balance between developer and operator personas. Developers need quick iteration and testing capabilities, while operators need reliable monitoring and production visibility. This unified view serves both: developers can test draft runs and iterate quickly, while the clear separation between draft and published runs ensures operators maintain full visibility into what's actually running in production. New Timeline View for Better Debugging We experimented with a timeline concept in Agentic Apps to explain handoff—Logic Apps' first foray into cyclic graphs. But it was confusing and didn't work well with other Logic App types. We've refined it. On the left-hand side, you'll now see a hierarchical view of every action your Logic App ran, in execution order. This makes navigation and debugging dramatically easier when you're trying to understand exactly what happened during a run. What's Next This is Phase I. We're shipping these improvements, but we're not stopping here. As we move into Phase II and beyond, I'll continue sharing updates through blog posts like this one. How to Share Your Feedback We're actively listening and want to hear from you: Use the feedback button in the Azure Portal designer Join the discussion in GitHub/Community Forum – https://github.com/Azure/LogicAppsUX Comment below with your thoughts and suggestions Your input directly shapes our roadmap and priorities. Keep the feedback coming. It's what drives these changes, and it's what will shape the future of Azure Logic Apps. Let's build something great together.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.
