Use connectors with Managed Identity in the Logic Apps Standard extension
Managed Identity is Azure’s built-in way to authenticate to Microsoft Entra-protected resources without storing credentials, secrets, or connection strings. Deployed Logic Apps have supported it for a while, but the developer inner loop was a different story. You would wire up one authentication method to run and debug locally, then swap it for another before deploying to the cloud. The Logic Apps Standard extension for Visual Studio Code now lets you create connectors that use Managed Identity as an authentication parameter and run them while you build and debug locally. This works for both Azure managed connectors and service provider connectors. When you run locally, the extension authenticates as your signed-in developer identity using the Azure default credentials pattern. After you deploy, the same connection authenticates with the app’s managed identity. Why this matters for developers You gain two things. Stronger security. Managed Identity removes the requirement to keep API keys or connection strings around to reach your target systems. As the Azure Logic Apps managed-identity guidance puts it, a managed identity “removes the need to store and manage credentials, secrets, or access tokens.” Fewer secrets in your settings mean a smaller attack surface and less to rotate. One setup for local and cloud. Many teams keep one authentication configuration for local runs and redefine it for cloud deployment, and those differences often cause deployment errors. With the Azure default credentials pattern, your app authenticates with your local sign-in while you develop, then with a managed identity after you deploy. The transition needs no code changes. One connection definition covers both environments. Prerequisites Make sure you are on these versions or later: Logic Apps Standard VS Code extension 5.961.19+ Bundle 1.165.52+ Azure CLI 2.51+ Az PowerShell module You must be logged on Azure CLI (using az login) and Az Powershell module (using Connect-AzAccount). How to enable Add the following app setting to both ./local.settings.json and ./workflow-designtime/local.settings.json: { "IsEncrypted": false, "Values": { "WORKFLOWS_AUTHENTICATION_METHOD": "managedServiceIdentity" } } Then reload the Visual Studio Code window so that both the extension and the design-time engine pick up the new setting. Both files matter. The design-time engine reads its own settings file to power the designer, so skipping it is a common reason the change does not take effect. From Logic Apps extension version 5.981.1, you can choose enable Managed Identity as an authentication method by default, by checking the following extension setting: If you are not ready to use managed identity yet, you can change the WORKFLOWS_AUTHENTICATION_METHOD value to Raw. But notice that this flag enables managed identity for the whole application, so if you are planning to use this feature you need it set to managedServiceIdentity. You might want to keep the existing behavior in case your existing CI/CD pipeline requires the Raw authentication method in connections.json or parameters.json. Also notice that this is a local only setting - it is added to local.settings.json files, which are not captured by source control. How it works This uses the Azure default credentials pattern. When your workflow needs a token, the credential chain tries a series of sources in order and stops at the first one that can issue a token. Locally, that resolves to your developer identity, such as your Azure CLI az login session, your Visual Studio Code sign-in, or Azure PowerShell. After you deploy, it resolves to the app’s managed identity, which can be system-assigned or user-assigned. The configuration stays the same across both environments. Whichever identity you use, your local user while developing or the managed identity once deployed, it needs the right RBAC roles on the resources it accesses. If a connection returns an authorization error, check the role assignment on the target resource first. The WORKFLOWS_AUTHENTICATION_METHOD flag behaves differently for each connector family. The next two sections cover both. Deep dive: Azure managed connectors For managed connectors, the flag does two things. It removes the requirement for a local connection key to authorize your logic app to talk to the managed connector, its access control layer (ACL). The change is transparent: the designer shows that you now have access to the connector. You can confirm it by inspecting the connection’s access policies. It authenticates the connector to the end system using the managed identity, or your user context when you run locally. You pick Managed Identity as the authentication type when you create the connection. Creating an Azure Blob Storage (managed) connection with Authentication Type set to “Logic Apps Managed Identity.” One limitation applies today. The Managed Identity implementation for managed connectors does not generate dynamic values inside the designer. You can still configure the connector, but you supply custom values instead of picking from dynamically populated dropdowns. Deep dive: Service provider connectors Service provider connectors support dynamic parameters today. You create the connection, choose Managed Identity as the authentication type, and keep using the designer’s dynamic values as usual, such as entering the fully qualified namespace for a Service Bus connection. Creating a Service Bus (service-provider) connection with Managed Identity. The connector supports dynamic parameters such as the Fully Qualified Namespace. Try it and let us know If you build integrations on Logic Apps Standard, update to the latest extension, set WORKFLOWS_AUTHENTICATION_METHOD to managedServiceIdentity, and give your connectors a passwordless local inner loop. This small setting removes secrets from your configuration and keeps authentication consistent from your laptop to the cloud. Have feedback, or a scenario you would like to see supported, such as dynamic values for managed connectors? Share it with the Logic Apps Aviators community at aka.ms/aistechcommunity. Your input shapes the roadmap. Learn more Authenticate connections with managed identities in Azure Logic Apps Create Standard logic app workflows with Visual Studio Code DefaultAzureCredential overview (Azure Identity client library)Logic Apps Aviators Newsletter - August 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month August 2026's Ace Aviator: Sonny Gillissen LinkedIn: https://www.linkedin.com/in/sonnygillissen/ What's your role and title? What are your responsibilities? Integration Architect / Cluster Lead I'm responsible for running Integration projects at our customers, and next to that I'm leading our team of Integration Experts by embedding our mission and vision deeply in the roots of our team. Can you give us some insights into your day-to-day activities and what a typical day in your role looks like? My day typically consists out of working together with my customer to validate our integration solutions and form next steps to provide the best fit. This could be meeting with the business to gather requirements, or check in with the team to find the best approach. From an internal perspective I'm working on our go-to-market to keep it aligned with the company's vision and movements in the market, together with our team of Integration Experts. What motivates and inspires you to be an active member of the Aviators/Microsoft community? The fact that it such an active community, and people are very much willing to help each other is what drives me te be an active member too. Especially when you could help someone with your expertise is what really makes my day and provides all the energy to keep outperforming myself, every single day. Looking back, what advice do you wish you had been given earlier that you'd now share with those looking to get into STEM/technology? You don't have to do everything alone. When working with techhology, it may feel like you're the only one at times, especially when you're hitting that one niche problem. But in fact, others can have such a positive impact, so keep asking. What has helped you grow professionally? First of, I really believe having a team of experts around you that you can collaborate with helped a lot. But on the other hand, actively sharing knowledge and digging into problems of others is what really helped me grow. Not only professionally, also as person. If you had a magic wand that could create a feature in Logic Apps, what would it be and why? This question was easier to answer when there wasn't a thing like Logic Apps Automation, as I believe this was my magic wand before: putting the power of integration in everyone's hand. But, with that said, I think it would be cool of you can have an “Logic Apps Agent” that creates and maintains your envisioned integration by itself, or with it’s Logic App co-workers (of course with some checkin’ in to you at times). In my opinion this would really bring the power of Logic Apps to literally everyone. News from our product group AI Gateway tier of API Management now in public preview The public-preview AI Gateway tier of Azure API Management provides a purpose-built experience for publishing and governing AI models, MCP servers, and tools. It supports models from Microsoft Foundry and other providers, connector-backed tools, card-based governance policies, Azure RBAC, and OpenTelemetry token-usage metrics. Changing the engine while the plane is flying: migrating 60,000 apps under live load This engineering account describes migrating roughly 60,000 Integration Account Function apps from end-of-life runtimes to Azure Functions v4 isolated worker. The team used shadow traffic, parity checks, progressive regional rollout, configuration-based rollback, privacy-preserving telemetry, and a stop-before-delete retirement process. Hybrid Logic Apps on RKE2: a self-managed cluster with MetalLB This walkthrough shows how to deploy Azure Logic Apps Hybrid on a self-managed RKE2 Kubernetes cluster using MetalLB. It covers Azure Arc, the Container Apps extension, custom locations, connected environments, ingress, and RKE2-specific fixes involving inotify limits, CoreDNS configuration, and the missing kube-dns service alias. Announcing Flat File Schema Generation support in Azure Logic Apps Standard Azure Logic Apps Standard now provides a preview built-in action that generates BizTalk-compatible flat-file XSD schemas at runtime from sample payloads. It supports common delimited and fixed-width formats and can feed generated schemas into Flat File Encoding or Decoding actions. Hybrid Logic Apps Deployment on Red Hat OpenShift This guide explains how to deploy Azure Logic Apps Hybrid on self-managed Red Hat OpenShift or Azure Red Hat OpenShift. It covers Azure Arc, SMB storage, OpenShift security context constraints, the Container Apps extension, custom locations, connected environments, ingress choices, DNS configuration, and troubleshooting. Coding with Logic Apps Standard: Local Functions This article introduces Local Functions in Azure Logic Apps Standard, which let developers write, debug, and deploy custom .NET code alongside workflows in the same project. Workflow-scoped code can share the Logic App’s deployment, scaling, security, and operational boundary without requiring a separate Azure Functions resource. Common scenarios include message validation, payload enrichment, custom parsing, business rules, and BizTalk modernization. The article also explains when Local Functions are preferable to independently hosted Azure Functions and how they fit into a unified CI/CD process. News from our community What's New with Logic Apps Post by Gabriel Yang The article reviews how announcements from Integrate 2026 move Azure Logic Apps toward a central role in enterprise automation and AI orchestration. It covers Logic Apps Automation, AI-assisted workflow authoring, Knowledge as a Service, direct Azure AI Foundry Agent invocation, the Logic Apps Standard SDK for C#, and Azure Connector Namespace access from custom applications. Together, these capabilities reduce infrastructure and integration complexity while retaining governance and scalability. The broader value is a more accessible orchestration layer connecting enterprise systems, knowledge, agents, and operational business processes. Monitoring Is Not Reconciliation Post by Al Ghoniem, MBA The article distinguishes technical monitoring from business reconciliation in enterprise integrations. Successful Logic Apps runs, Service Bus metrics, and API responses show that known work executed, but cannot prove every expected transaction reached the target correctly. Effective reconciliation compares expected and actual states using independent reference sets, stable business identifiers, appropriate timing windows, and risk-based matching depth. It also requires liveness checks, explicit ownership, and controlled recovery decisions. The approach helps detect missing, duplicate, late, or inconsistent transactions before customers, auditors, or downstream controls expose them. Power Automate's Big Brother - Azure Functions Connector Namespaces Video by Sean Astrakhan The video demonstrates using Azure Functions connector namespaces to trigger Python code from services such as Dataverse, Outlook, and SharePoint. A Dataverse record-creation scenario invokes a function that populates an expiration date, with GitHub Copilot helping author, deploy, and test the solution. The example also highlights the need to direct Copilot toward connector namespaces instead of older HTTP-trigger and webhook patterns. This approach combines managed connector access with pro-code flexibility, reducing separate flow and connection requirements while making Azure Functions more approachable for integration developers. Building Stateful Agentic AI Workflows with Azure Standard Logic Apps Post by Sakshi Mittal The guide explains how stateful agentic workflows extend Azure Logic Apps Standard beyond fixed API orchestration. It compares autonomous agents for repetitive background tasks with conversational agents for interactive scenarios, then outlines prerequisites such as AI model access, connectors, RBAC, managed identities, and Application Insights. It contrasts adaptive agent state with conventional workflow run state and reviews benefits including automation, scale, and contextual decisions. It also highlights trade-offs around cost, nondeterminism, debugging, privacy, latency, and governance, helping teams choose an appropriate pattern before production. Logic Apps Automation Preview Post by Steef-Jan Wiggers This assessment examines Logic Apps Automation as a managed, single-tenant experience with Microsoft-managed capacity, a project-and-application hierarchy, agent tooling, sandboxed code execution, and real-time run history. A failure-triage example shows how agents can use runbook knowledge and structured outputs while deterministic branches control tickets and retries. The article also identifies preview limitations, including missing CI/CD, ownership transfer, audit visibility, and uncertain network support. Its central recommendation is to pilot nonregulated workloads while defining project ownership, app-level access, governance, and deployment requirements before broader enterprise adoption. Azure Logic Apps Standard | Testing Series Post by Andrew Wilson The article introduces a practical testing series for Azure Logic Apps Standard, addressing reliance on manual runs and run-history inspection as workflow estates grow. It proposes layered validation covering testable workflow design, mocked action outputs, unit tests derived from workflow definitions in Visual Studio Code, integration tests, and agent-assisted testing. The approach emphasizes deterministic boundaries, separation of orchestration from connector-heavy implementation, observability through tracking and correlation, and behavior-focused environment parity. These practices aim to create faster feedback, clearer regression detection, and repeatable confidence across frequent workflow changes and deployments. Mastering Error Handling and Retry Design in Logic Apps Post by Parth T. Distributed workflows routinely face timeouts, throttling, network interruptions, and unavailable dependencies, making resilience a core Logic Apps design concern. The article outlines how to identify likely failure points, use fallback paths and compensating actions, and apply bounded retries with exponential backoff and idempotent operations. It also emphasizes thorough logging, correlation identifiers, stakeholder notifications, and deliberate testing of failure scenarios such as invalid responses and partial execution. These practices help teams prevent cascading failures, improve diagnosis, and maintain stable business processes when transient or permanent faults occur. Introduction to Knowledge Base as a Service KBaaS | Built-In Knowledge for Azure Logic Apps Video by Srikanth Gunnala Building retrieval-augmented agents normally requires document chunking, embeddings, a vector store, retrieval logic, and orchestration. This video introduces Knowledge Base as a Service in Azure Logic Apps, which manages those components behind a built-in knowledge-base experience. It demonstrates connecting Azure Cosmos DB and Azure OpenAI, uploading documentation, and attaching the resulting knowledge base to a conversational agent. An internal API documentation assistant provides the practical scenario, showing how an agent can answer questions with responses grounded in uploaded source material while reducing custom RAG infrastructure and setup work. Knowledge Base as a Service in Azure Logic Apps Post by Steef-Jan Wiggers Knowledge retrieval for Logic Apps agents has traditionally required a separately configured search index, indexer, data source, chunking strategy, and embeddings pipeline. This walkthrough explains how the preview Knowledge Base as a Service capability instead parses, chunks, summarizes, vectorizes, and stores uploaded content through Azure Cosmos DB and Azure OpenAI. An HR policy agent demonstrates grounded answers, citations, and appropriate fallback for out-of-scope questions. The article also provides deployment steps, a Bicep-based sample, and practical notes on portal persistence, connection configuration, model availability, authentication, and workflow schema requirements. Vibe Coding Logic Apps in Azure: Automating Complex Workflows with AI Assistance Post by Marcel Broschk The article examines how natural-language, AI-assisted development can accelerate Azure Logic Apps workflow creation without replacing engineering judgment. It covers the native workflow assistant, GitHub Copilot scaffolding, structured prompts, agent-and-workflow patterns, MCP servers, and AI-oriented designs such as retrieval-augmented generation. It also recommends repository-level Copilot instructions, automated tests, static analysis, security controls, and human review. The approach helps integration teams move from intent to deployable workflows faster while retaining responsibility for architecture, authentication, error handling, governance, and operational reliability. Are Azure Logic Apps really low-code or no-code? Post by Chris Bradshaw The article evaluates whether Azure Logic Apps is genuinely no-code and concludes that low-code is the more accurate description. Simple connector-based workflows may require no coding, but production integrations commonly involve expressions, JSON editing, error handling, transformations, infrastructure as code, deployment pipelines, and governance. It offers practical guidance for choosing Logic Apps for orchestration and visible workflows, Azure Functions for custom logic and performance, or a hybrid architecture combining both. This framing helps teams match each service to the problem rather than relying on marketing labels. Azure Logic Apps at Integrate 2026: The Announcements Post by Steef-Jan Wiggers The article reviews five Azure Logic Apps announcements from Integrate 2026 and their implications for integration architects. It covers Logic Apps Automation, Knowledge as a Service, native Azure AI Foundry agent integration, the Logic Apps Standard SDK, and Azure Connector Namespace. Together, these capabilities simplify managed workflow hosting, retrieval-augmented generation, agent orchestration, code-first C# development, and connector reuse outside the workflow runtime. The analysis positions Logic Apps as an enterprise AI connectivity and orchestration layer and recommends revisiting hosting, knowledge retrieval, and SDK adoption decisions. Azure Logic Apps Agent Loop Production Operations Post by Steef-Jan Wiggers Production agent loops require more than successful workflow runs. This article explains how Standard Logic Apps can use Application Insights, run history, and KQL queries to monitor requests, dependencies, exceptions, tool calls, token use, and execution duration. It compares Standard and Consumption pricing, outlines tool, throttling, and conversation-history limits, and describes repeatable deployment through source-controlled workflow definitions, zip deployment, Azure CLI, and environment-specific settings. The guidance helps teams evaluate operational readiness, cost behavior, observability, and deployment practices before moving agentic workflows into production. Event-Driven Automation Post by Uttam Chaturvedi File-arrival notifications can be automated with an Azure Logic Apps Consumption workflow. This walkthrough creates a private Blob Storage container, configures a blob-created trigger, sends file metadata to a REST endpoint through an HTTP action, and emails the team through Office 365 Outlook. It also covers resource organization, testing, run history, security, pricing, and possible extensions such as Teams notifications, SQL persistence, Azure Functions, approvals, and CI/CD deployment. The pattern demonstrates event-driven integration without manually operated scripts or continuously running servers. Azure Logic Apps Tracking Properties – A Complete Team Guide (Part 2) Post by Sandro Pereira Tracking Properties improve Logic Apps observability by adding relevant business and technical context to action telemetry. This guide shows how to configure them on individual actions through the designer’s Settings pane or the trackedProperties section in code view. Values may be static, dynamic, or combined, although expressions must be entered manually without IntelliSense and should be validated carefully. Recommended practices include tracking useful identifiers, standardizing property names, keeping values concise, and excluding credentials or personal data, making Log Analytics queries, dashboards, monitoring, and troubleshooting more consistent. Navigating Cost Pitfalls in Logic App Consumption Plans Post by Parth T. Consumption-based Logic Apps can accumulate unexpected charges through frequent polling, premium connectors, redundant actions, large loops, unnecessary runs, retries, API calls, and oversized payloads. This article recommends event-based triggers, appropriate polling intervals, trigger conditions, simpler workflow logic, filtered or batched processing, and reduced connector calls. It also advises continuous monitoring with Azure Monitor and Cost Management, budgets and alerts, periodic execution reviews, managed identities, and documented architectures. These practices support more predictable spending while preserving workflow performance, scalability, governance, and operational visibility. Streamlining Logic Apps: The Importance of Versioning and CI/CD Post by Parth T. Reliable Logic Apps delivery requires disciplined change tracking and automated deployment rather than manual updates. This article explains how version control supports traceability, collaboration, audits, troubleshooting, and rollback, while CI/CD validates, tests, and promotes workflow changes consistently across environments. Recommended practices include semantic versioning, Git repositories, feature branches, ARM or Bicep infrastructure definitions, parameterized environment settings, Key Vault secrets, approval gates, release notes, monitoring, and rollback plans. Together, these methods reduce deployment risk and downtime while improving release speed, consistency, governance, and maintainability.
Announcing Flat File Schema Generation support in Azure Logic Apps Standard
We’re excited to announce the preview of Flat File Schema Generation for Azure Logic Apps Standard. This new built-in action helps integration teams move faster by generating BizTalk compatible flat-file XSD schemas directly from sample flat-file payloads, reducing the manual effort required to model CSV, delimited, and positional files before encoding or decoding them in workflows. Why this matters Flat files continue to power enterprise mission critical integrations, from partner feeds and batch exports to finance ledgers, operational reports, and legacy system exchanges. While Azure Logic Apps already helps teams encode and decode flat files, creating the required flat-file schema has often been a separate design-time step. With Flat File Schema Generation, you can now accelerate that onboarding experience by generating a starter schema from real sample data within the workflow itself. What’s new The new Flat File Schema Generation action generates a flat-file XSD schema from sample content that you pass into the action. The generated schema includes BizTalk-compatible flat-file annotations, making it suitable for downstream Flat File Encoding and Flat File Decoding actions in Azure Logic Apps Standard workflows. Runtime schema generation: Generate schemas directly from sample flat-file payloads in the workflow. Delimited and positional support: Create schemas for common CSV, semicolon-delimited, tab-delimited, and fixed-width files. BizTalk-compatible annotations: Use generated schemas with the existing flat-file processing model familiar to BizTalk and enterprise integration teams. Flexible naming: Configure root element names, namespaces, record names, delimiters, and field positions to match your integration needs. How it works You provide a representative sample payload, specify whether the file structure is delimited or positional, and configure the relevant parsing details such as field delimiters, record delimiters, header handling, or fixed-width field positions. Once you run the workflow, the action returns the generated XSD schema as XML output, which can then be passed into subsequent flat-file operations or stored as part of your onboarding flow. Get started To try the preview, add the Flat File Schema Generation action to a Logic Apps Standard workflow, provide a sample flat-file payload, choose the record structure, and configure the field or record settings that match your format. Use the generated schema output with Flat File Decoding or Encoding in the same workflow or incorporate it into your broader onboarding process for flat-file integrations. Reference document: Encode, Decode, or Generate Schemas for Flat Files - Azure Logic Apps | Microsoft Learn. A walkthrough of generating a flat-file schema from sample data Use the following walkthrough to try the preview end to end with a simple customer order file. The same pattern can be adapted for semicolon-delimited, tab-delimited, or fixed-width positional files. Delimited sample: For this example, assume a trading partner sends a comma-separated order file with a header row and repeating order records. Sample file: OrderId,CustomerName,OrderDate,Amount,Region 10001,Contoso Retail,2026-07-01,1250.75,North 10002,Fabrikam Foods,2026-07-02,890.00,West 10003,Northwind Traders,2026-07-03,2400.50,South Configuration values Parameter Example value Record Structure Delimited Has header Yes Record delimiter newline Field delimiter , Field delimiter order Infix Escape character Double quote, if the source file uses quoted values Root element name (Advanced Parameters) Orders Record name (Advanced Parameters) Order Target namespace (Advanced Parameters) http://schemas.contoso.com/orders In the Azure portal, open your Logic Apps Standard resource and select the workflow where you want to generate the schema. Add a trigger, such as When an HTTP request is received, or use any trigger/action that provides the sample flat-file content. Add a new action and search for Flat File. Select the Flat File Schema Generation action. In the action, provide the sample flat-file content. Select the file structure type. For this example, choose Delimited. Enter the schema metadata under advanced parameters, such as the root element name, record name, and target namespace. Configure the delimiter settings, including the field delimiter and record delimiter. If the first row contains column names, enable the option to use the first row as headers. Save and run the workflow. Open the workflow run history and review the action output. The action returns a generated XSD schema with flat-file annotations. Review the generated schema, validate field names and inferred data types, and use the schema with Flat File Decoding or Flat File Encoding in your workflow. Positional sample: Fixed-width customer order file Use this example when the source flat file doesn’t use delimiters. In a positional, or fixed-width, file each field starts and ends at a known character position. The schema generation action needs those field positions so it can split each record correctly. Sample positional file: 10001CONTOSO00120260701000125075NORTH 10002FABRIKAM0120260702000089000WEST· 10003NORTHWIND120260703000240050SOUTH Note: The dot symbol in the second record represents a trailing space used for fixed-width padding. Replace it with an actual space in your real sample payload. Field position map Field Start position Length Justification Example value OrderId 1 5 Right 10001 CustomerCode 6 10 Left CONTOSO001 OrderDate 16 8 Right 20260701 Amount 24 9 Right 000125075 Region 33 5 Left NORTH Configuration values for the positional sample Parameter Example value Record Structure Positional Has Header No Record delimiter newline Field positions Use the field names, lengths, and justification values from the field position map. Root element name (Advanced Parameters) Orders Record name (Advanced Parameters) Order Target namespace (Advanced Parameters) http://schemas.contoso.com/orders/positional Step-by-step walkthrough for positional files In the Azure portal, open your Logic Apps Standard resource and select the workflow where you want to generate the schema. Add a trigger, such as When an HTTP request is received, or use an existing action that provides the fixed-width file content. Add a new action and search for Flat File. Select the Flat File Schema Generation action. Paste the positional sample payload into the sample content input. Make sure every record has the same total length. For the structure type, choose Positional. Enter the schema metadata, including root element name, record name, and target namespace. Configure the record delimiter. For this example, use newline. Add the field positions in order: OrderId length 5, CustomerCode length 10, OrderDate length 8, Amount length 9, and Region length 5. Set justification for each field. Use Right for numeric or date-like fields and Left for text fields that may contain trailing space padding. Save and run the workflow. Open the workflow run history and review the generated XSD schema output. Confirm that the field names, order, lengths, and positional annotations match the source record layout. Use the generated schema with Flat File Decoding to parse incoming fixed-width files into XML, or with Flat File Encoding to generate outbound fixed-width files. Limitations and known issues Limitation Description Type inference uses a single record. The first non-empty data record determines column types. Single record type only The action generates one repeating record structure and doesn't support heterogeneous record layouts. No nested or hierarchical records The generated schema is flat, meaning you have a root element with one repeating child record and fields. Positional boundaries aren't automatically detected. You must provide exact field lengths in field Positions. UTF-8 code page only Generated schema sets codepage="65001" and doesn't expose encoding selection. Escape-character behavior is literal. Escape handling matches literal value and skips only the next single character. recordName default If unspecified, defaults to {RootElementName}_Record. Designer justification input fieldPositions[].justification supports only Left and Right. Looking ahead This preview is another step toward making Azure Logic Apps Standard, a more complete and productive platform for enterprise integration modernization. Whether you are onboarding new partner feeds, modernizing BizTalk-style flat-file processing, or automating recurring operational files, Flat File Schema Generation helps reduce setup friction and get integration workflows moving faster.
Azure Event Grid with ASB
Hi, we need to push Event Grid events for blob creation to an Azure Service Bis queue to deduplicate as the EG guarantee "At least one delivery" pattern, but the problem is that we need to deduplicate with blob name as "MessageId" on ASB side. The problem is that the blob name is not present in the event data. we have only "subject" with the full url that can exceed 128 characters, the limit of ASb Messageid. In some duplicate events I found that the filed "data/storageDiagnostics/batchId" is the same for duplicated events. I'm wonderring if this batchId will be always the same for duplicate events, I can use it as "MessagesId" in "Delivery properties"On the road to .NET 10 Support: Logic Apps Migration from In-Proc to Out-of-Proc hosting model
We will begin this migration in the coming weeks. For most customers, the change will be automatic and require no action. However, some apps will need customer updates before they can move to the new hosting model. This exception is: Logic Apps that use the current NuGet-based deployment model If your app does not fall into one of these categories, it will be migrated automatically and no action is required. If it does, review the guidance in this article to prepare your app for migration. Getting ready for this update If your application is using NuGet-based deployment, you should update your deployment processes to preserve the following app setting until your app is ready to move to the new hosting model: LOGICAPP_INPROC_REDIRECT 1 This app setting is used to prevent an app from being automatically migrated to the Azure Functions out-of-proc-hosting model. We will update this app setting for apps that fall into the exception categories and will notify customers to update their deployment pipelines so this value is not overwritten. We will start rolling out a change that will automatically move any app that does not have the above app setting to the Azure Functions out-of-proc-hosting model the next time the app restarts. As part of the rollout process, we will add this flag to any application that fits the exception criteria. This will be done only once, so subsequent configuration changes could override our setting. This is why you need to update your processes to preserve this value until the app is ready to move. You must make this change before July 30, 2026. This is when we will be rolling out the changes. Manual steps needed for NuGet-based applications If your application is using the NuGet-base deployment model, you will need to make the appropriate updates described below before removing the redirect app setting and allowing the app to move to the Azure Functions out-of-proc-hosting model. Download the latest Azure Functions Core Tools. Update your project configuration to the Azure Functions out-of-proc-hosting model. Validate your application locally before updating your deployment process and removing the redirect app setting. After you have validated your application locally and updated your deployment process, you can remove the redirect app setting and allow the deployed app to move to the Azure Functions out-of-proc-hosting model when appropriate guidance has been published for your scenario. Frequently Asked Questions Q: How do I prevent my app from being migrated to the Azure Functions out-of-proc-hosting model? The LOGICAPP_INPROC_REDIRECT setting is used to determine whether an app should remain on the current in-proc hosting model. By default, apps that do not have this setting will be moved to the Azure Functions out-of-proc-hosting model. Set the value to 1 if you need to prevent automatic migration until your app is ready. Q: What happens if my app uses the NuGet deployment model? If your app uses the NuGet deployment model, you should keep the redirect app setting in place for now. We will publish a separate communication when the required Logic Apps runtime package guidance and supported migration steps are confirmed for this scenario. Q: Q: What happens if I accidentally remove the LOGICAPP_INPROC_REDIRECT = 1 from my configuration? The LOGICAPP_INPROC_REDIRECT setting is used to determine whether an app should remain on the current in-proc hosting model. If you remove it by accidenty, your application will be moved to the Azure Functions out-of-proc-hosting model. But you can reset that behavior by reapplying the setting and restarting the application. Q: Will there be a separate communication about .NET 10 support? Yes. We will send a separate communication once we have confirmed the Logic Apps runtime and workflow version guidance for .NET 10 support.Logic Apps Aviators Newsletter - June 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month June 2026's Ace Aviator: Florian De Langhe LinkedIn: https://www.linkedin.com/in/floriandelanghe/ What's your role and title? What are your responsibilities? Lead Expert/Team Lead for the Microsoft Integration team at delaware. I have a wide range of responsibilities: - People management - Resource planning - Design and operate our integration solutions at our customers, what we brand as "SmartLink". Next to this, as many of us, I follow the latest AI news closely to keep up to date and try to stay ahead of the curve. Can you give us some insights into your day-to-day activities? I wear many hats so no two days look the same. That is also what keeps it interesting. A typical day starts with reviewing resource planning across our active projects, followed by a technical design review for a new integration. Sprinkle some one-on-one coaching conversations and research into new technologies/features and you have my day. The balance between People leadership and hands-on technical work is what I enjoy most. What motivates and inspires you to be an active member of the Aviators/Microsoft community? I started out being an active member on the Microsoft Logic App forum 10 years ago. I remember going back and forth with Wagner through the forum posts trying to solve questions. Good times. Integration is one of those disciplines where you're constantly connecting systems, teams, and ideas. What motivates me is seeing how members of our community across different companies and countries solve similar problems in completely different ways. The Aviators community has that right mix of deep technical knowledge and willingness to help each other out. Since discovering Integration and the Microsoft community, I basically never left. Looking back, what advice do you wish you had been given earlier? Document everything and treat documentation as a deliverable, not an afterthought. Early in my career I saw documentation as the boring part that you do after the development work. Now I see it as the leverage point. A well-written design document doesn't just help the next person understand what you built, it compounds. It feeds code generation, easier onboarding of new members and validation with your customers on what and how to build it. What has helped you grow professionally? Two things: 1) Always challenge yourself and your implementations; everything can be better, so I am always pushing myself to keep learning, stay up to date, and think about every idea/solution posted in this community—how it could improve my way of thinking or solutions that I am building/have built. 2) Focus on understanding the integration concepts and patterns. At the end of the day everything is a pattern; it is how you implement where we make the difference. So knowing the base layer itself helps a lot when building integration solutions. If you had a magic wand that could create a feature in Logic Apps, what would it be? To be able to control scaling of the workflow service plans more fine grained. Being able to control this would unlock a lot of use cases, especially for the combination of Logic Apps and Service Bus concurrency and throughput. News from our product group Write Logic Apps in C#: introducing the Logic Apps Standard SDK This article introduces the Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk), a code-first way to define Logic Apps Standard workflows in C#. Developers compose workflows using a fluent builder with strongly typed triggers and actions, including both built-in and managed connector operations. The SDK preserves the existing runtime, connectors, monitoring, and run history while changing only the authoring experience. It supports control flow constructs, custom C# code steps, and run-after conditions for fault handling. Guidance covers getting started in VS Code, project layout, local F5 execution, and preview limitations such as no service provider connectors and work-in-progress managed identity support. New AI gateway capabilities in Azure API Management Azure API Management expands its AI gateway with a Unified Model API (preview) that lets clients use a single OpenAI-style format across providers, plus model aliases and discovery. GA updates include support for Anthropic and Google Vertex AI and content safety for MCP and Agent-to-Agent (A2A) traffic. Token observability now tracks cached, reasoning, and thinking tokens in Application Insights. Foundry import adds Anthropic API operations. A2A APIs reach GA with richer diagnostics and availability in classic tiers. Together, these features standardize governance, security, and observability for multi-model, multi-protocol AI applications. 🎉 Automation just became a team sport. Meet Azure Logic Apps Automation. Azure Logic Apps Automation (public preview) is a new SKU that delivers a managed, SaaS-like experience for building and running workflow automations. It keeps the enterprise-grade Logic Apps engine while simplifying onboarding, collaboration, and governance with projects and applications, flexible permissions, and policy inheritance. The experience is AI-native with natural language authoring, first-class agents, tools via MCP, and managed sandboxes. It introduces a modern designer, draft mode, live run history, JavaScript expressions, elastic scale to zero, and knowledge-as-a-service integration—aimed at helping teams prototype quickly and operate securely at scale. 📢 Announcing Knowledge as a Service for Azure Logic Apps Knowledge as a Service (public preview) provides a managed knowledge layer for Logic Apps that turns documents into a ready-to-use knowledge base without building a custom RAG pipeline. The service handles ingestion (parsing, chunking, embeddings) and retrieval (query rewriting, semantic search, ranking) and integrates with agentic workflows in Logic Apps Standard and the Automation SKU. On Standard, teams bring their own vector store and models; on Automation, the platform hosts them on behalf of the user. It supports Entra authentication and focuses on secure, grounded responses for agents and workflows. Better Together: Build Agents in Microsoft Foundry, Automate them with Azure Logic Apps This post outlines a combined stack for agentic applications: Microsoft Foundry for building and hosting agents, and Azure Logic Apps for invoking and orchestrating them. New capabilities let teams create or select Foundry agents directly from the Logic Apps designer, pair any trigger with an agent for autonomous execution, and expose 1,400+ Logic Apps connectors and entire workflows as agent tools. The approach enables agents to act across systems, handle long-running processes, and integrate with enterprise events, making deterministic workflows and AI-driven reasoning work together in production. What's new in Azure API Management at Microsoft Build 2026 This roundup covers Build 2026 updates for API Management and API Center: GA for agent registration, assessment, and Git sync in API Center, plus a data plane MCP server for enterprise discovery. API Management adds GA support for JSON‑RPC agent‑to‑agent (A2A) APIs and extends content safety controls to MCP and A2A flows. Unified Model API enters preview to standardize client integration across model providers, and AI Gateway expands to Anthropic and Vertex AI with broader token metrics. Platform enhancements include multi‑domain and wildcard custom hostnames in v2 tiers and workspace support on the built‑in gateway. Azure Connector Namespaces: managed integration for any Azure compute Azure Connector Namespace (preview) offers a fully managed integration layer that brings the Logic Apps connector ecosystem to any Azure or self‑hosted compute without requiring a workflow engine. Apps call strongly typed SDKs for C#, Node.js, or Python to invoke actions and subscribe to triggers, while the namespace handles auth, token rotation, retries, throttling, and webhook delivery. It also projects connectors as MCP servers for agents, and supports hosted MCP servers like Playwright and Azure SQL. The post details building blocks, scenarios, security, governance, and preview limitations. What's new in Azure Logic Apps at Microsoft Build 2026 This Build 2026 overview highlights Logic Apps Automation (public preview), GA for the Logic Apps MCP Server to expose workflows as MCP tools, direct invocation of Microsoft Foundry agents from Logic Apps, Knowledge as a Service, and code‑first development with the Logic Apps Standard SDK (Codeful Workflows). It also introduces a Migration Agent to help modernize from legacy platforms. The theme is making enterprise‑grade automation more accessible while preserving governance, reliability, and operational controls for production use. Hosted MCP Servers in Connector Namespace (Preview) Hosted MCP servers in Connector Namespace let teams deploy managed, enterprise‑ready MCP servers from a curated catalog in minutes. The platform handles deployment, scaling, authentication (inbound with Entra ID, outbound with managed identity or on‑behalf‑of), availability, and observability via Application Insights. Preview servers include Playwright for browser automation and Azure SQL via Data API Builder, enabling agents to use reliable tools without the overhead of self‑hosting. The post explains setup, benefits over self‑hosted servers, and areas of ongoing investment like catalog expansion and VNet support. MCP Test Console and Git Repository synch in Azure API Center Azure API Center adds a built‑in MCP Test Console in the developer portal and Git repository synchronization for MCP servers and other assets. Developers can validate MCP tools interactively on the Documentation tab and browse server tiles with endpoints and schemas. Git sync keeps the API Center inventory aligned with source‑controlled definitions, with secure access via Key Vault and managed identity. Together, these additions streamline discovery, testing, and governance of MCP assets across the enterprise. Bringing all your Integration workloads to Logic Apps Standard This post outlines Microsoft’s guided path for moving enterprise integration workloads—especially BizTalk—to Azure Logic Apps Standard. It introduces the open-source Logic Apps Migration Agent, which delivers an AI‑assisted, stage‑gated process across discovery, planning, baseline conversion, and continuous validation with human‑in‑the‑loop checkpoints. The workflow integrates with VS Code and GitHub Copilot, supports incremental “flow‑group” migration, and accommodates existing black‑box tests. The article also previews mission‑critical capabilities arriving for Standard and Hybrid (HL7, MLLP, Rules Engine, MSMQ, Oracle DB, flat‑file generation, Integration Accounts, and more), giving teams a repeatable, auditable modernization path with reduced risk. Announcing Microsoft Host Integration Server 2028: Modern connectivity for IBM Mainframes Midranges Host Integration Server 2028 (HIS 2028) is the next HIS release, delivered as a standalone SKU decoupled from BizTalk. It modernizes platform foundations (.NET 10) and, for non‑SNA features, introduces Linux support. New investments include Foundry integration for agent scenarios, REST APIs for DB2 and Transaction Integrator workloads, Entra ID and Azure Arc for hybrid management, a move to Visual Studio Code for designers, and alignment with newer IBM middleware. The post also lists product cleanup and deprecations (e.g., 32‑bit, WMI/WCF, BizTalk adapters), helping enterprises secure, govern, and operate host connectivity for years ahead. Easy Auth Configuration for Logic App Standard through CI/CD Enabling App Service Easy Auth on Logic Apps Standard can break run‑history views because SAS‑based runtime calls are blocked before the Logic Apps engine can validate them. This article explains two remedies: allow unauthenticated requests (so the runtime enforces its own auth), or keep Easy Auth strict and exclude runtime endpoints (e.g., /runtime/*) using authsettingsV2. It provides CI/CD‑ready approaches via ARM/Bicep templates or a post‑deployment REST API call, and highlights key settings such as requireAuthentication, unauthenticatedClientAction, excludedPaths, and allowedApplications. The guidance restores run‑history usability while maintaining enterprise authentication policies. Run Javascript code on Agent Loop Azure Logic Apps Agent Loop now supports a JavaScript code interpreter, extending earlier code‑execution support and enabling reliable computations, validations, and transformations alongside LLMs. The runtime executes generated or pre‑written code inside a V8 isolate using the isolated‑vm library, providing memory limits, timeouts, and failure isolation (not a full sandbox) to reduce blast radius. A worked example shows expense‑validation with agent tools orchestrated in a workflow. For Consumption, attaching an Integration Account provides isolated compute for the interpreter. The capability helps teams combine deterministic steps with agentic reasoning to deliver robust, auditable outcomes. Bulk-configure diagnostic settings on Azure Logic Apps Consumptions LA‑BulkDiag is a single‑file PowerShell script that bulk‑applies diagnostic settings across Logic Apps Consumption in a resource group. It inventories workflows, supports quick scopes (bare/all/pick), verifies destinations, auto‑renames on name collisions, and ships with 129 Pester tests. Presets cover logs, metrics, and workflow‑runtime categories; selection grammar enables non‑interactive runs suitable for CI. The post includes quick‑start commands and clarifies scope: it targets Consumption only (not Standard) and doesn’t configure Event Hub sinks. The result is faster, consistent observability at scale without repetitive portal clicks or accidental overwrites. Clean up idle and always-failing Azure Logic App Consumption LA‑CleanUp is a PowerShell utility that scans a subscription for Logic Apps Consumption workflows, classifying them as Idle (no runs in N days) or AlwaysFailing (runs in the window with zero successes). It can export candidates to CSV, then guide per‑item deletion with y/N/q prompts, reporting final counts. Under the hood, it uses OData filters and $top=1 queries for fast server‑side checks, caches an ARM token once, and intentionally avoids cross‑subscription operations. Scope notes: it doesn’t touch Standard workflows or API connections. The tool reduces noise, costs, and operational drag from abandoned or broken apps. News from our community Spec2Integration Post by Balbir Singh Spec2Integration proposes a spec-driven approach to building Azure Integration Services solutions. The open-source toolkit guides teams from a product brief through specification, modeling, contracts, mapping, and architecture to a deployable implementation targeting Azure Logic Apps, Functions, and related services. It includes governance gates for idempotency, observability, retries, and PII handling, plus a VS Code extension that visualizes pipeline status and the integration representation. Templates and tooling support greenfield projects and BizTalk migrations. The result aims to standardize repeatable steps, reduce failure modes, and accelerate delivery while keeping architectural control outside individual workflows. Stateful Orchestration in Azure: When Logic Apps Break, and What to Do Instead Post by Al Ghoniem, MBA This article examines where stateful orchestration with Azure Logic Apps can fall short and how to design around those gaps. It differentiates execution state from business state and highlights common failure modes: long-running instances, retry-induced duplicates, partial completion across SAP/Oracle/APIs, lost correlation, and unowned DLQs. It then contrasts orchestration choices—stateful Logic Apps, Durable Functions, Service Bus–backed orchestration, and choreography—emphasizing idempotency, correlation, reconciliation, and compensation. The guidance steers architects toward a control and observability layer so production incidents can be traced, replayed, and recovered without relying on workflow run history alone. Logic Apps Announcements at Microsoft Build Video by Sebastian Meyer This video recaps Logic Apps announcements from Microsoft Build with insights from a member of the product team. It highlights newly introduced capabilities and shares resources for deeper dives. Viewers get a concise overview of what’s new, why it matters for integration practitioners, and where to learn more. The discussion points architects toward practical use cases and next steps, making it a useful primer for anyone assessing roadmap impacts on existing or upcoming Azure Integration Services projects. Logic Apps Standard vs. Consumption: Which Plan Should You Choose? Post by Chiranjib Ghatak The article compares Logic Apps Standard and Consumption, explaining differences in hosting models, pricing, networking, and development experience. It outlines when to pick each plan, noting Standard’s single-tenant model, VNet/private endpoints, built-in connectors, and local DevOps workflow, versus Consumption’s pay-per-execution model and simplicity for sporadic or low-volume workloads. It also covers performance trade-offs, stateful vs. stateless options available in Standard, and typical enterprise scenarios where Standard provides predictable costs and better throughput. Azure Connector Namespaces: Managed Connectors Beyond Logic Apps Post by Şahin Özdemir This post introduces Azure Connector Namespaces and previews managed connectors for Azure Functions, extending the Logic Apps connector ecosystem to more compute services. It explains the motivation, how namespaces decouple connectors from workflows, and the benefits: reduced custom code, consistent authentication via managed identity, and reuse of Microsoft-managed integrations. A step-by-step walkthrough shows creating a namespace, adding a managed connector, and using the Azure Connectors .NET SDK in Functions, illustrating how teams can standardize connectivity while keeping business logic in code. Stop working harder and start flowing smarter, with Logic Apps Automation Post by Sonny Gillissen Sonny Gillissen explores Logic Apps Automation, a new, governed experience for building enterprise automations. He explains the Project → Application → Workflow model, dedicated portal (auto.azure.com), and reusable Sandboxes for agent code. The post shows how the AI assistant can scaffold workflows from intent, with Knowledge sources to ground agents, while monitoring and analytics provide visibility. Benefits include familiar Logic Apps design, reduced operational overhead, and scale-to-zero. Current gaps are noted—OBO auth shift, occasional assistant syntax issues, managed vs. built‑in connector choices, no migration tooling yet, and pending VNet/private endpoint support. Stop Using Static Filters! Automate DIXF Exports with Logic App Post by Anitha Eswaran Anitha Eswaran demonstrates how to make DIXF exports in D365FO dynamic using Azure Logic Apps and a small X++ customization. A custom OData action updates the DIXF Definition Group filter at runtime based on a parameter such as Customer Group. A Logic App triggered by a business event parses the input, stores the value, calls the OData action, invokes the standard ExportToPackage API, and then retrieves the download URL via GetExportedPackageUrl to fetch the ZIP with a time‑limited SAS token. Screenshots and code samples illustrate the end‑to‑end flow and implementation details. Logic Apps Agent Loops: Master Class Video by Stephen W Thomas Stephen W Thomas compiles his full Logic Apps Agent Loop series into one master‑class video. It covers getting started with Agent Loop on Logic Apps Standard, a human‑in‑the‑loop pattern used to resolve failed code translations, interactive chat agents with secure website embedding via Easy Auth, and when to choose the Consumption tier for simpler, pay‑as‑you‑go deployments. The chaptered format lets viewers jump to relevant topics. The emphasis is on the orchestration pattern—agents that select and compose tools to achieve goals—offering a practical foundation for teams moving from deterministic workflows toward agentic automation. Forget Sampling — This One host.json Setting Cuts Logic Apps Telemetry Costs by 80% Post by Daniel Jonathan This article tackles high Application Insights ingestion costs in Logic Apps Standard and shows a data‑driven path to reduce spend. Through a controlled experiment, it demonstrates that switching Runtime.ApplicationInsightTelemetryVersion to v2 in host.json delivers ~80% reduction without sacrificing troubleshooting. Further options include disabling dependency tracking (eliminates AppDependencies with the trade‑off of losing per‑call HTTP detail) and using adaptive sampling for marginal additional savings, while excluding exceptions. It also explains why some run‑level telemetry bypasses sampling and how to toggle sampling via an environment variable for short‑term diagnostics. Production Is the Only Truth in Integration Post by Marcelo Gomes This piece reframes integration success through a production‑first lens. It argues that reliability emerges when systems are designed for failure as the norm, not the exception. The article urges separating orchestration from business logic—using tools like Azure Logic Apps for coordination and Azure Functions for rules and transformations—to keep retries safe and evolution predictable. It positions production‑readiness as a design concern, emphasizing idempotency, replay, observability, runbooks, and ownership. The practical outcome is reduced operational risk and cost, more predictable behavior, and greater business trust in automated processes. DevUP Talks #05 – Logic Apps Tips & Tricks with Sandro Pereira Video by Mattias Lögdberg In this session, Sandro Pereira distills practical guidance from real projects to help teams build more resilient Logic Apps. Topics include applying environment‑specific timer conditions, deploying Logic Apps in a disabled state to control activation during releases, and using User‑Managed Identity with Azure Service Bus in Logic Apps Standard. The video focuses on patterns that improve reliability, security, and operational control across environments, offering actionable advice for developers and architects working in Azure Integration Services who want fewer surprises in production and a smoother deployment lifecycle. Logic Apps: Service Bus with User‑Assigned Managed Identity Post by Sandro Pereira This best‑practices guide shows how to configure the Azure Service Bus connector in Logic Apps Standard to use a user‑assigned managed identity. Sandro Pereira explains why system‑assigned identities complicate CI/CD—RBAC can’t be fully declared until the identity exists—then demonstrates a pattern that keeps deployments reproducible. The approach uses app settings for the Service Bus namespace and identity resource ID, a custom serviceProviderConnections entry referencing those settings, and workflow actions bound to that connection. The result is secretless, declarative authentication that avoids RBAC timing issues across environments. Logic App Consumption Bulk Failed Runs Resubmit Tool Post by Sandro Pereira Sandro Pereira introduces a small .NET Windows utility that lists and bulk resubmits failed Logic Apps Consumption runs. After authenticating to Azure, users supply the Logic App name, resource group and subscription. The tool can optionally filter by a date range, otherwise it returns up to 250 failed runs for fast triage. It targets a common pain point the portal features don’t fully streamline and includes a link to the GitHub source so teams can adapt or integrate it into operational workflows. A concise “one‑minute brief” outlines the problem and practical benefits. Control the Initial State of Logic Apps Standard Workflows Post by Sandro Pereira This tip explains how to prevent Logic Apps Standard workflows from starting immediately after deployment—a common production risk. Instead of a state property in ARM/Bicep, the initial state is controlled via App Settings on the underlying App Service. By setting Workflows..FlowState to Disabled (in local.settings.json and/or app settings), teams ensure workflows deploy in a safe, non‑running state. The article outlines the rationale, differences from Consumption, and provides concrete examples and screenshots to adopt the practice across environments.Write Logic Apps in C#: introducing the Logic Apps Standard SDK
The workflow you always wished you could write in code If you build on Logic Apps Standard, you already know the deal: the runtime is excellent at the unglamorous parts of integration - connecting to systems, retrying, scaling, keeping run history you can actually debug. What you sometimes wanted was a different front door. You're a .NET developer. You live in C#, source control, and pull requests. And for a long time, authoring a workflow meant leaving all of that behind for a visual designer and a JSON file. That's the gap the new Logic Apps Standard SDK closes. It lets you define Logic Apps Standard workflows in code - strongly typed, IntelliSense-guided C# - without giving up a single thing the runtime already does for you. What is the Logic Apps Standard SDK? The Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk) is a NuGet package that gives you a fluent, code-first way to build workflow definitions in C#. Instead of dragging actions onto a canvas, you compose a workflow with method chaining: a trigger, then the actions that follow it, all the way to a response. Worth saying clearly, because people ask: this is a new way to define workflows - not a new runtime. The workflows you write with the SDK compile down to the same definitions and run on the same Logic Apps Standard runtime you use today. Same connectors. Same hosting. Same rich run history and monitoring. You're changing the authoring experience, not the engine underneath it. Why this matters for developers When your workflow lives in C#, it behaves like the rest of your code. A few things fall out of that almost for free: Type safety and IntelliSense - connector operations, triggers, and outputs are discoverable as you type, and the compiler catches mistakes before you run anything. Real source control and reviews - workflows diff like code, get reviewed in pull requests, and version alongside the services they orchestrate. Familiar tooling - refactor, debug with F5, and lean on the .NET ecosystem you already know. Extensibility on your terms — Compose your workflow declaratively with the fluent builder, then drop into plain imperative C# wherever a step needs logic that might be too complex to implement declaratively - loops, branching, a call into your own library, all encapsulated in a step of your workflow - without leaving the file or the language. And it isn't limited to one style of work. The SDK covers both enterprise integration workflows - the connect-systems-and-move-data scenarios Logic Apps is known for - and agentic workflows, where a conversational or autonomous AI agent drives the steps. Both are first-class in the same SDK, built from the same building blocks. There's one more angle worth calling out, because it's becoming hard to ignore: coding agents are simply better at writing imperative code than declarative JSON. And the reason is the same set of guardrails that helps you. Strong typing and a compilation step mean the code an agent produces is syntactically correct out of the gate — the type system and the compiler do the checking, so you don't have to. Layer unit tests on top and you've covered north of 90% of what matters; what's left is integration testing. Getting an LLM to the same level of accuracy against declarative JSON means building dedicated tooling to stand in for everything the compiler gives you for free. With code-first workflows, those guardrails are just there — which makes this a natural fit for an agent-assisted way of building. Getting started Everything here lives in the Logic Apps extension for VS Code. You'll want the Logic Apps Standard VS Code extension version 5.961.10 or later, which includes all the components you need to create code first workflows. Beyond that, the prerequisites are the ones you'd expect - VS Code with the Logic Apps extension, an Azure subscription you can create resources in, and a working comfort with C# and .NET. From a clean start, you're a handful of steps from a running workflow: Create the workspace — launch the Logic Apps extension and choose Create new Logic Apps workspace. Pick a folder, name the workspace and project, and when prompted for the workflow type, choose Logic Apps codeful - that's the code-first option that uses the SDK. Pick a workflow kind - name your first workflow and choose how it runs: Stateful, Autonomous agents (Preview), or Conversational agents (Preview). The agent options are where the agentic scenarios live. Enable connectors - when prompted, select Use connectors from Azure, choose your subscription and resource group, and pick Connection Keys for authentication. Managed identity is still in development, so connection keys are the way in for now. Find your way around - the project opens with Program.cs, which builds and starts the host, plus a workflow file (like workflow1.cs) where your trigger and actions are defined. The SDK compiles those definitions and runs them on the Logic Apps runtime. Run it - press F5 (or right-click Program.cs and pick Overview). The runtime starts locally and an overview page opens where you can fire triggers, watch run history, and inspect inputs and outputs. That last part is worth dwelling on: run history for SDK workflows uses the same rich visual view as designer-built ones. You author in code, but you monitor and troubleshoot exactly as you always have. A look at the capabilities Connectors and triggers Every workflow starts with a trigger and runs a series of actions. The SDK exposes both through two entry points - WorkflowTriggers and WorkflowActions - each split into BuiltIn and Managed. Built-in triggers and actions run directly in the runtime: HTTP request, recurrence, and the conversational agent trigger; actions like Compose, HTTP, Response, and custom code. Managed connectors give you the full Logic Apps connector catalog - Service Bus, SharePoint, SQL, and hundreds more - typed and ready to call. The managed surface is generated from the same connector definitions the designer uses, so the operations you know are right there: // Built-in trigger var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // Managed connector action — full catalog, strongly typed var getItems = WorkflowActions.Managed .Sharepointonline("sharepoint") .GetItems( dataset: () => "https://contoso.sharepoint.com", table: () => "orders-list-id") .WithName("GetOrders"); The fluent API streamlines the definition This is where it comes together. You compose a workflow by chaining operations with .Then(...). The shape of your code mirrors the shape of your workflow - read it top to bottom and you read the execution path. trigger .Then(validateOrder) .Then(getOrders) .Then(sendResponse); Control flow is part of the same fluent model. Built-in structures like Condition (if/else) and ForEach - along with Switch, Until, Scope, and Terminate - are just actions you chain in, each taking a small factory for the branch or loop body: var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => order.Total > 1000, trueBranch: () => requireApproval, falseBranch: () => autoApprove ).WithName("CheckOrderValue"); And ForEach takes the collection to iterate and a factory that builds the body for each item: var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => order.LineItems, actions: (item) => new WorkflowBuiltInActions() .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); Need parallel branches that fan back in? The same Then pattern handles branching and join - no JSON wiring, no run-after blocks to hand-edit. Extending workflows with custom code Some logic doesn't belong in a connector or an expression - it's just code. The CustomCode action lets you drop a real C# method into the middle of a workflow. It receives a WorkflowContext, so you can read the trigger payload or any earlier action's results and return a strongly typed value the next step can use: var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var trigger = await context.GetTriggerResults(); var order = await context.GetActionResults("GetOrders"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); That's the escape hatch that keeps you in flow: when a step needs custom transformation, validation, or a call into your own libraries, you write a method instead of bending an expression to do something it was never meant to. Handling failures: try/catch with run-after Real workflows have to deal with things going wrong, and the SDK gives you the same try/catch shape Logic Apps has always had - expressed in code. The .Then(...) overload takes a FlowStatus[] run-after condition, so a handler runs only when the step before it ends in a status you name. Wrap the risky work in a Scope (your try), then chain a handler that runs after it Failed or TimedOut (your catch): var tryProcess = WorkflowActions.BuiltIn.Control.Scope(() => callPaymentApi.Then(saveOrder) ).WithName("ProcessPayment"); var handleFailure = WorkflowActions.BuiltIn .Compose(inputs: () => "Payment failed — compensating") .WithName("HandleFailure"); trigger .Then(tryProcess) .Then(handleFailure, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); The status set is the whole vocabulary: Succeeded, Failed, Skipped, and TimedOut. Combine them however a step needs - a cleanup action that should run no matter what can list every status; a finally is just the union. The same idea scales to fan-in. When several parallel branches converge, the per-predecessor RunAfter overload lets the join wait on each branch independently - so you can require some to succeed and tolerate others failing: leftChain .Join(rightChain) .Then(merge, runAfter: new[] { new RunAfter(leftChain, FlowStatus.Succeeded), new RunAfter(rightChain, FlowStatus.Succeeded), }); Putting it together Here's a small but complete shape - an HTTP-triggered order workflow that validates input, branches on order value, loops over line items, runs custom code, and replies. The core steps live in a Scope so a single failure handler can catch anything that goes wrong, and a clean reply only runs when the work succeeds. Notice it's all one readable chain: namespace LogicApps { using Microsoft.Azure.Workflows.Sdk; using Microsoft.Azure.Workflows.Sdk.Connectors.Msnweather; using System.Net; public class OrderWorkflow : IWorkflowProvider { /// <summary> /// Gets the HTTP request/response workflow definition. /// </summary> public FlowDefinition[] GetWorkflows() { // --- Trigger ---------------------------------------------------- var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // --- Managed connector action (full catalog, strongly typed) ---- // Reused verbatim from the confirmed stateful1.cs pattern. var getWeather = WorkflowActions.Managed.Msnweather("msnweather").CurrentWeather( location: () => "98058", units: () => unitsInput.Imperial).WithName("GetWeather"); // --- Custom code: real C# in the middle of the workflow --------- var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var triggerResults = await context.GetTriggerResults(); var weather = await context.GetActionResults("GetWeather"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); // --- ForEach over a collection (control flow via .Control) ------- var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => trigger.TriggerOutput.Body["lineItems"], actions: (item) => WorkflowActions.BuiltIn .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); // --- Condition (if/else) (control flow via .Control) ------------ var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => true, trueBranch: () => processLines, falseBranch: () => WorkflowActions.BuiltIn .Compose(inputs: () => "Auto-approved").WithName("AutoApprove") ).WithName("CheckOrderValue"); // --- Scope groups the core steps so one handler catches failures - var processOrder = WorkflowActions.BuiltIn.Control.Scope(() => checkTotal .Then(getWeather) .Then(enrich) ).WithName("ProcessOrder"); // --- Responses -------------------------------------------------- var ok = WorkflowActions.BuiltIn.Response( responseBody: () => "Order processed").WithName("Reply"); var failed = WorkflowActions.BuiltIn.Response( statusCode: () => HttpStatusCode.InternalServerError, responseBody: () => "Order failed").WithName("ReplyFailed"); // --- Assemble --------------------------------------------------- // Happy path runs after the Scope Succeeded; the handler runs after // Failed or TimedOut. trigger .Then(processOrder) .Then(ok, runAfter: new[] { FlowStatus.Succeeded }) .Then(failed, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); return new[] { WorkflowFactory.CreateStatefulWorkflow("OrderWorkflow", trigger) }; } } } That last stretch is the best-practice shape in miniature: the happy-path Reply runs only after the Scope Succeeded, while a separate handler catches Failed or TimedOut and returns a 500 - no exception plumbing, just run-after conditions. You implement IWorkflowProvider, hand your trigger graph to WorkflowFactory as a stateful, stateless, or agent workflow, and the host registers it. Run it with F5 and the Logic Apps runtime starts locally - same as any Standard project. Before you build: preview realities I'd rather you go in clear-eyed. While the SDK is in public preview, keep these in mind: Service Provider connectors aren't supported yet - that connector type is coming in a future release. Dynamic schemas aren't supported - support is planned. Custom code supports callback methods only - inline lambdas aren't available in this version. Define and name actions before referencing them - name an action before using it as a dependency elsewhere. Managed identity authentication is in development - use connection keys for connectors in the meantime. Try it, and tell us what you think If you've ever wanted your workflows to live where the rest of your code lives - in C#, in source control, in your pull requests - this is for you. Install the Logic Apps extension for VS Code, create a Logic Apps codeful project, and build your first workflow in code. This is a preview, which means your feedback genuinely shapes where it goes - which capabilities come next, where the rough edges are. Bring issues, feature requests and feedback to our GitHub page. I read it. Let's make code-first workflows something you actually want to use. Related content Create Standard workflow projects with the SDK Logic Apps Standard SDK class libraryWhat's new in Azure API Management at Microsoft Build 2026
For more than a decade, Azure API Management has helped organizations secure, govern, and operate APIs at enterprise scale. As organizations build more AI-powered applications, APIs are increasingly part of a broader architecture that includes AI models, agents, MCP tools, and agent-to-agent interactions. These new patterns increase the need for consistent governance, discovery, security, and observability across the full application ecosystem. Azure API Management already provides AI gateway capabilities that help organizations govern and observe AI workloads. At Build 2026, we're continuing to expand those capabilities and introducing new updates that help organizations manage the growing ecosystem of APIs, models, agents, MCP tools, and AI-powered interactions. General Availability: Azure API Center expands discovery and governance for APIs and AI assets As organizations build more AI-powered applications, APIs are no longer the only reusable enterprise asset. Agents, MCP tools, prompts, skills, and AI services are rapidly becoming building blocks that developers need to discover, evaluate, and reuse. To support this shift, Azure API Center now Azure API Center now supports agent registration, agent assessment, and Git-based synchronization | Microsoft Community Hub, helping organizations create a centralized catalog for APIs and AI assets. Developers can register agents directly into API Center, making them discoverable alongside APIs and other enterprise assets. Agent definitions can be synchronized automatically from Git repositories, ensuring catalog entries remain aligned with source-controlled implementations and evolving codebases. To help organizations establish trust and quality standards, API Center now also provides automated agent assessment using an LLM-as-a-Judge framework. Agents can be evaluated for safety, reliability, and behavioral completeness before being published to the enterprise catalog. We're also announcing the general availability of the Azure API Center data plane MCP server. As organizations adopt MCP-based tooling and AI agents at scale, developers need a simpler way to discover and connect to the growing ecosystem of enterprise MCP servers, tools, APIs, agents, and AI assets. The Azure API Center data plane MCP server acts as a unified enterprise discovery endpoint, enabling agents and developer tools to access registered MCP servers, tools, APIs, agents, and AI assets through a single MCP connection. This allows organizations to provide centralized access to enterprise capabilities, simplify discovery across growing catalogs, and automatically make newly registered MCP servers and tools available without requiring individual client reconfiguration. Together with agent registration, assessment, and Git synchronization, the Azure API Center data plane MCP server helps organizations create a centralized source of truth for APIs, agents, MCP tools, and AI assets improving discoverability, governance, and reuse across the enterprise General Availability: Agent-to-Agent APIs and content safety controls Agentic systems introduce new governance challenges. As agents begin coordinating work on behalf of applications and users, agent-to-agent communication is becoming an increasingly important architectural pattern. Historically, these interactions have often existed outside traditional API governance boundaries, creating operational blind spots and fragmented governance models. Azure API Management now supports JSON-RPC-based Agent-to-Agent (A2A) APIs, enabling organizations to manage agent interactions alongside REST APIs, GraphQL APIs, MCP tools, and AI model APIs using the same API management platform they already rely on today. We're also extending content safety capabilities to MCP tools and A2A interactions. Organizations can now centrally apply safety controls across model invocations, tool execution, and agent communication patterns through a unified governance layer. Rather than introducing separate governance platforms for agents, Azure API Management enables organizations to extend familiar API governance principles to emerging agent ecosystems. Public Preview: Unified Model API for multi-model AI applications Most organizations are quickly discovering that AI is becoming a multi-model world. Applications increasingly combine models from Microsoft, OpenAI, Anthropic, Google, and other providers based on performance, cost, latency, regional requirements, or workload-specific needs. This creates complexity for developers and platform teams alike. Different providers expose different APIs. SDKs vary. Governance becomes fragmented. Switching providers often requires application changes. To simplify multi-model architectures, we're introducing the Unified Model API in public preview. The Unified Model API allows organizations to standardize on a single client-facing API format while Azure API Management transparently handles provider-specific transformations behind the scenes. Developers can continue using familiar APIs and SDKs while platform teams gain the flexibility to route traffic across multiple providers, implement failover strategies, and evolve model choices over time. By abstracting provider-specific differences behind a unified API layer, organizations can build more portable, resilient, and governable AI applications. General Availability: Expanded AI Gateway support for Anthropic and Vertex AI Azure API Management AI gateway capabilities already helps organizations govern and observe AI traffic across model providers. As multi-model architectures become increasingly common, organizations need consistent governance regardless of where those models are hosted. API Management now extends AI Gateway capabilities to Anthropic and Google Vertex AI models. Organizations can apply runtime governance, security controls, content safety policies, semantic caching, token controls, logging, tracing, and observability across a broader range of AI providers. This enables platform teams to apply consistent governance practices across multi-model environments without introducing separate management tools or operational processes for each provider. General Availability: Expanded token observability for AI workloads Understanding AI usage is becoming increasingly important as model providers introduce new token types beyond traditional prompt and completion tokens. Azure API Management now supports token metrics for all token types, including cached, reasoning, and thinking tokens, with metrics available through Application Insights. Organizations can collect token usage data across multiple providers and API formats, build more accurate cost dashboards, improve budget monitoring, and gain deeper visibility into evolving model behaviors. As AI workloads continue to grow, expanded token observability helps organizations better manage costs, optimize usage, and strengthen governance across AI applications. General Availability: Enterprise platform enhancements Alongside our AI-focused investments, we're continuing to expand the core platform capabilities organizations rely on to operate API programs at scale. Azure API Management Premium v2 now supports multiple custom domains, allowing organizations to expose APIs, developer portals, and management endpoints under multiple branded experiences while maintaining centralized governance. Azure API Management Premium v2 and Standard v2 now support wildcard custom hostnames, significantly reducing certificate and hostname management overhead for growing API estates. We're also expanding workspace support to the built-in gateway. Organizations can now adopt team-based governance and delegated API management models across additional deployment options while benefiting from built-in gateway capabilities such as multi-region deployments, custom hostnames, and Private Link connectivity. Together, these enhancements make it easier for organizations to scale up API programs while maintaining operational simplicity. Looking ahead APIs remain the foundation of modern applications. But increasingly, they are no longer the only assets developers interact with. Models, agents, MCP tools, and agent-to-agent interactions are becoming important components of enterprise application architectures. The governance challenge is no longer limited to APIs alone. With these Build announcements, Azure API Management and Azure API Center continue to expand the governance foundation organizations rely onhelping teams discover, secure, govern, and observe APIs, models, agents, MCP tools, and AI interactions through a unified platform experience. As organizations build the next generation of AI-powered applications, we're committed to providing the governance, security, visibility, and operational controls required to run those systems with confidence at enterprise scale.What's new in Azure Logic Apps at Microsoft Build 2026
Automation is entering a new era Automation has traditionally been powerful, but not always accessible. Building production-grade automations often requires specialized expertise in workflows, integrations, APIs, infrastructure, identity, security, networking, and operations. Organizations could build sophisticated solutions, but doing so typically requires dedicated development or integration teams AI is changing that equation. Across every organization, more people want to automate work. Developers want to build AI-powered applications faster. Startup teams want to move from idea to production without assembling complex infrastructure. Operations, security, and business teams want to leverage AI to automate repetitive processes and accelerate decision making. Expectations have changed as well. Builders increasingly expect natural language experiences, AI assistance, integrated knowledge, and faster paths from idea to execution. At the same time, organizations still need the governance, security, reliability, compliance, and operational controls required to run automation in production. This creates a new opportunity: making enterprise-grade automation accessible to far more builders without sacrificing the foundations required to operate at scale. At Build 2026, we're introducing Azure Logic Apps Automation along with several new Azure Logic Apps capabilities that help organizations build, connect, and operationalize AI-powered automation on Azure. Public Preview: Azure Logic Apps Automation Azure Logic Apps Automation is a new Logic Apps SKU designed to make enterprise-grade automation dramatically easier to build. Built on the same Azure platform organizations trust today, Logic Apps Automation provides a managed environment where workflows, AI agents, enterprise connectivity, knowledge services, and model access are available out of the box. A built-in AI assistant helps users move from intent to implementation using natural language. Developers can generate workflows, configure actions, create expressions, and build automations faster while maintaining full control over the final implementation. Logic Apps Automation also brings AI agents directly into the automation experience. Developers can build and use Microsoft Foundry agents alongside traditional workflow actions, enabling business processes that combine deterministic execution with AI-driven reasoning. Whether you're a startup building AI-native applications, an enterprise modernizing internal processes, or a developer looking to accelerate automation projects, Logic Apps Automation provides a simpler path from idea to production. General Availability: Azure Logic Apps MCP Server As AI agents become increasingly important participants in enterprise applications, organizations need a straightforward way to connect those agents to existing business processes. The Azure Logic Apps MCP Server is now generally available and enables developers to expose existing Logic Apps workflows as MCP-compatible tools that agents can discover and invoke directly. This allows organizations to reuse years of existing automation investments without building custom APIs or integration layers. Workflows that already connect enterprise systems, business applications, and operational processes can now become AI-callable capabilities in minutes. Public Preview: Invoke Microsoft Foundry Agents directly from Logic Apps Organizations increasingly build agents in Microsoft Foundry. With new Foundry integration capabilities, developers can now invoke Foundry agents directly from Logic Apps workflows. This enables business processes that combine enterprise systems, APIs, human approvals, schedules, events, and AI-driven reasoning within a single automation experience. Workflows can trigger agents, agents can provide analysis or recommendations, and Logic Apps coordinates the broader business process around those outcomes. Public Preview: Knowledge as a Service One of the biggest challenges organizations face when building AI-powered applications is making enterprise knowledge accessible. Retrieval-augmented generation often requires ingestion pipelines, chunking strategies, embedding models, vector databases, and retrieval infrastructure before developers can begin building the experiences they actually care about. Knowledge as a Service simplifies this process. Developers can upload documents directly into Logic Apps workflows, automatically ingest and process content, generate embeddings, and use retrieval as a built-in workflow capability. Instead of building and operating knowledge infrastructure, teams can focus on creating grounded AI experiences and intelligent automations that leverage organizational knowledge. Public Preview: Codeful Workflows with the Logic Apps Standard SDK Different developers prefer different ways of building software. Some teams prefer visual workflow design. Others want the flexibility and familiarity of code-first development. Codeful Workflows introduces a new code-first development experience for Azure Logic Apps Standard. Built on the Logic Apps Standard SDK, Codeful Workflows enable developers to create workflows directly in code using familiar .NET development patterns while continuing to benefit from Logic Apps connectors, orchestration capabilities, and operational infrastructure. Developers can build, test, debug, and run workflows locally while leveraging existing development tools, source control practices, and AI-assisted coding experiences. This gives teams more flexibility in how they build automation while preserving the benefits of the Logic Apps platform. Public Preview: Migration Agent for Azure Logic Apps Modernization remains a top priority for many organizations as they evaluate legacy integration platforms and prepare for the next generation of cloud-native architectures. The new Migration Agent for Azure Logic Apps helps simplify that journey. Designed to assist organizations migrating from BizTalk Server and other third-party integration solutions, the Migration Agent provides intelligent assessments, migration guidance, compatibility analysis, and automated recommendations. By reducing the manual effort traditionally associated with migration projects, organizations can accelerate modernization initiatives while lowering risk and improving confidence throughout the migration process. Looking ahead The future of automation is not simply about adding AI to existing workflows. It's about making powerful automation accessible to more builders while preserving the governance, reliability, security, and operational controls organizations require. Azure Logic Apps has long provided the foundation for enterprise integration and business process automation. With Logic Apps Automation, Foundry agent integration, MCP support, Knowledge as a Service, Codeful Workflows, and AI-powered migration capabilities, we're continuing to expand what's possible while making it easier for organizations to move from idea to production. We're excited to see what developers, startups, enterprises, and builders of every kind create next.
Clean up idle and always-failing Azure Logic App Consumption
If you’ve inherited an Azure subscription that’s been collecting Logic Apps Consumption workflows for a couple of years, you already know the shape of the problem: dozens of TestLA, webhook-test-2, poc-for-jira-FINAL workflows in the portal, half of them still Enabled, half of them quietly failing every five minutes against a connection that was rotated last quarter. They’re cheap, but they’re not free — polling triggers keep firing, alert rules keep paging, abandoned Microsoft.Web/connections keep pinning permissions, and the portal’s workflow list keeps getting harder to read. Source + full docs: GitHub - dengyanbo/LA-CleanUp What it gives you Two color-coded tables — Idle (no runs in the last -IdleDays days; never-run workflows land here too) and AlwaysFailing (ran in the window, but not a single Succeeded ). An optional, timestamped CSV ( LogicAppCleanup-Candidates-<yyyyMMdd-HHmmss>.csv ) with a stable column set, easy to drop in a Teams channel or PR for owner review before you delete anything. A per-item y/N/q deletion loop — y deletes, N /Enter skips, q quits the loop without touching anything else. A final summary with scanned / idle / always-failing / deleted / skipped / failed counts. Server-side OData $filter on run history so the scan is fast even on a subscription with thousands of workflow runs in the window. Lazy State lookup (Enabled/Disabled) — only fetched for actual candidates, not for every healthy workflow. What it is not: it does not touch Logic Apps Standard ( Microsoft.Web/sites with kind=workflowapp ) — those store run history in storage tables and need a completely different tool (see LogicAppAdvancedTool). It also does not GC Microsoft.Web/connections , and it does not iterate subscriptions — one invocation, one subscription, deliberately. Quick start Prerequisites PowerShell 5.1+ (Windows PowerShell or PowerShell 7 — both fine). Azure CLI on PATH: https://aka.ms/azcli An interactive az login against the subscription that owns the Logic Apps. Logic App Contributor on the relevant RGs (or plain Contributor) is enough — you need list + delete on Microsoft.Logic/workflows , plus the ARM token your az login already grants. Get the script git clone https://github.com/dengyanbo/LA-CleanUp.git cd LA-CleanUp One-liner — defaults (90-day idle, 90-day failure window, current sub) .\Invoke-LogicAppCleanup.ps1 A typical run looks like this: [INFO] Active subscription: Contoso-Integration (1111-2222-...) [INFO] Signed in as : alice@contoso.com [INFO] Idle cutoff : runs older than 2026-02-20T03:08:00Z (>90 days) [INFO] Failure window : checking runs since 2026-02-20T03:08:00Z (last 90 days) [INFO] Listing Logic App (Consumption) workflows... [ OK ] Found 13 workflow(s). [ 1/13] order-processor (rg-integration) [ 2/13] webhook-test (MyTest) ... [ OK ] Scan complete. Idle: 9, AlwaysFailing: 1, Errors: 0 === Idle Logic Apps (no runs in last 90 days) === Name ResourceGroup Location State LastStatus LastRunTime ---- ------------- -------- ----- ---------- ----------- webhook-test MyTest australiaeast Enabled Never poc-for-jira rg-integration eastus Enabled Succeeded 2025-09-04T... ... === Always-Failing Logic Apps (no successful run in last 90 days) === Name ResourceGroup Location State LastStatus LastRunTime ---- ------------- -------- ----- ---------- ----------- nightly-export rg-integration eastus Enabled Failed 2026-05-20T... Export the 10 candidate(s) to CSV? (y/N): y [ OK ] CSV written: ...\LogicAppCleanup-Candidates-20260521-110800.csv Starting per-item deletion review. Answer y to delete, N (or Enter) to skip, q to quit. (1/10) Delete [Idle] webhook-test in MyTest ? (y/N/q): y [INFO] Deleting webhook-test ... [ OK ] Deleted: webhook-test (2/10) Delete [Idle] poc-for-jira in rg-integration ? (y/N/q): N Skipped. ... === Summary === Scanned : 13 Idle : 9 Always-failing : 1 Scan errors : 0 Deleted : 4 Skipped : 6 Delete failures : 0 That’s the whole workflow. The commands you’ll actually use 1. Scope to one resource group with a tighter idle threshold .\Invoke-LogicAppCleanup.ps1 -IdleDays 60 -ResourceGroup rg-integration 2. Only review always-failing apps (skip the idle pile) .\Invoke-LogicAppCleanup.ps1 -SkipIdle 3. Only review idle apps (skip always-failing) .\Invoke-LogicAppCleanup.ps1 -SkipAlwaysFailing 4. Incident-driven cleanup — tight window, focused RG .\Invoke-LogicAppCleanup.ps1 -IdleDays 30 -FailureWindowDays 7 ` -ResourceGroup rg-integration-prod This answers: “Within prod-integration, which workflows haven’t run in a month, and which have been failing all week?” 5. Dry-run (there is no -WhatIf ) The per-item y/N/q prompt is the safety model. To dry-run, just answer N to every prompt — or q at the first one. The CSV is still written before the deletion loop starts, so you walk away with the report and zero deletions. Parameters — cheat sheet Parameter Default Meaning -IdleDays 90 No runs in this many days ⇒ flagged Idle. Never-run workflows land here too. -FailureWindowDays 90 Ran in this window but no Succeeded ⇒ flagged AlwaysFailing. -ResourceGroup (none) Restrict the scan to a single RG. -SkipIdle switch Skip the Idle bucket entirely. -SkipAlwaysFailing switch Skip the AlwaysFailing bucket entirely. Why Invoke-RestMethod instead of az rest This is the gotcha I want every other Logic Apps scripter to know about, because it eats hours. The Logic Apps Management REST API is queried with OData — $top , $filter , the usual: GET /subscriptions/.../workflows/{wf}/runs ?api-version=2016-06-01 &$top=1 &$filter=startTime ge 2026-02-20T03:08:00Z and status eq 'Succeeded' On Windows PowerShell, az is a .cmd shim. The URL you pass to az rest --uri "..." is re-parsed by cmd.exe , and the & characters separating OData query parameters get interpreted as command separators. Symptoms range from '$filter' is not recognized as an internal or external command to silent wrong-page returns where the filter is just dropped and you get the most recent N runs instead. Quoting heroics — single quotes, double quotes, triple-escaped ^& — don’t fully solve it across PS 5.1 and PS 7. The fix is to skip az rest entirely. The script grabs an ARM token once with az account get-access-token , caches it on a script-scoped variable, refreshes it proactively at the 45-minute mark (ARM tokens last ~60), and calls Invoke-RestMethod directly: $tok = az account get-access-token --resource 'https://management.azure.com/' -o json | ConvertFrom-Json Invoke-RestMethod -Method Get -Uri $url ` -Headers @{ Authorization = "Bearer $($tok.accessToken)" } That bypasses cmd.exe entirely. Bonus: caching the token makes the script noticeably faster on subscriptions with many candidates, since we’re no longer shelling out to az for every REST call. Why $top=1 matters more than you’d think The script never pages run history. For each surviving workflow it asks two existence questions: ?api-version=2016-06-01&$top=1&$filter=startTime ge <cutoff> ?api-version=2016-06-01&$top=1&$filter=startTime ge <cutoff> and status eq 'Succeeded' If the first one returns zero rows ⇒ the workflow is Idle. Otherwise, if the second one returns zero rows ⇒ AlwaysFailing. Both queries are O(1) server-side because startTime is indexed and the response is capped at one row. Even on a chatty workflow with tens of thousands of runs in the window, the answer comes back in tens of milliseconds. This is also why the script can afford to be sequential per workflow — there’s no need for parallelism when each existence check is essentially free. Why “AlwaysFailing” is defined the way it is The bucket is “ran in the window, but not a single Succeeded run in the window” — not “all runs are Failed ”. That distinction matters: Workflows whose runs are Running , Waiting , or Cancelled but never Succeeded get classified as AlwaysFailing. That’s usually what you want — a workflow that has been “Waiting” for 30 days is just as broken as one that’s been failing for 30 days. Long-running workflows that legitimately haven’t completed yet look the same to the classifier. If you operate that kind of workflow, widen -FailureWindowDays so a slow but eventually-Succeeded run shows up in the window. The reported LastStatus column in the table is the status of the most recent run, so you can usually eyeball the difference between “failing” and “still running.” A field-tested rollout If you’re running this on a subscription you don’t fully own, this multi-pass rollout has worked well: Run with -SkipAlwaysFailing first. Idle workflows are the safe pile — if they haven’t done anything in 90+ days, deleting them rarely surprises anyone. Export the CSV. Don’t delete yet — answer q at the first delete prompt. Drop the CSV in a Teams channel or PR. Give owners a few days to object. Re-run and actually delete the ones nobody claimed. Then run with -SkipIdle for the AlwaysFailing bucket. These often have an owner who just hasn’t noticed the breakage — treat the first pass as a bug-bash list, not a delete list. Things to know before you run it Consumption only. Logic Apps Standard is out of scope — different model, different APIs, run history in storage tables. Use LogicAppAdvancedTool for those. No -Force , no -WhatIf . The per-item y/N/q prompt is the entire safety model. That’s deliberate — cleanup tools that take a -Force get used with -Force . One subscription per invocation. The script operates on whatever az account show returns. Use az account set --subscription <id> to switch deliberately. Microsoft.Web/connections are not deleted. API connections are typically shared; the script intentionally leaves them alone. GC them with a separate pass. Run history disappears with the workflow. Once you delete the Logic App, Azure removes its run history too. Export the CSV first if you want any record. Enabled vs. Disabled is reported, not enforced. A Disabled workflow can still be Idle. The script shows the state in the table so you can decide. Where to go next The GitHub repo has the full reference — parameter table, CSV schema, the “how it works” deep dive on lazy State fetch, bearer-token caching, server-side $filter , considerations and limitations, and the recommended rollout: 👉 https://github.com/dengyanbo/LA-CleanUp Issues and PRs welcome. A few directions on the roadmap: an optional disable-instead-of-delete mode for the first pass ( PATCH ...?api-version=2019-05-01 with properties.state = 'Disabled' ), a cross-subscription mode that iterates az account list with a confirmation per sub, and a companion API-connection GC script that uses Resource Graph to join connections against workflow definitions in one query.
