Modernize Any Integration Platform to Azure Logic Apps Standard with the Logic Apps Migration Agent
Explore the open-source Logic Apps Migration Agent Enterprise integration is entering a new era Enterprise integration platforms have powered business-critical processes for decades. They connect applications, data, partners, devices, and industries, often carrying transactions that an organization cannot afford to interrupt. Expectations have changed. Organizations want cloud-native architectures, AI-assisted automation, stronger governance, improved developer productivity, and faster response to business change. Yet many integration estates contain years of accumulated dependencies, custom code, transformations, operational procedures, and platform-specific knowledge. The challenge is not simply moving an orchestration or flow from one runtime to another. This is not lift and shift. It is a refactoring exercise that preserves business intent and expected behavior while translating source-platform constructs into cloud-ready workflows, connectors, code, operational patterns, and deployment practices for Azure Logic Apps Standard. That is why we created the Logic Apps Migration Agent. Introducing the Logic Apps Migration Agent: An Open-source project to provide an AI End-to-End Modernization Experience The Logic Apps Migration Agent is an open-source Visual Studio Code extension that provides an AI-assisted, end-to-end modernization experience. It uses GitHub Copilot and the Visual Studio Code Language Model API to guide teams through a structured five-stage workflow, while keeping people in control at every stage. Rather than treating modernization as a single conversion step, the agent helps teams discover what they have, understand dependencies, design an appropriate target, generate baseline implementation artifacts, validate expected behavior, and prepare the solution for deployment to Azure Logic Apps Standard. Refactor the implementation, preserve the business intent Lift and shift attempts to reproduce the source platform as closely as possible in a new environment. That approach can carry forward legacy topology, operational assumptions, platform-specific patterns, and technical debt. The Migration Agent supports a different outcome. It uses the source implementation as evidence of the required business behavior, then helps teams design and generate an appropriate Logic Apps Standard implementation. Some components may map directly, while others require restructuring, consolidation, decomposition, replacement, or custom implementation. The objective is functional and semantic continuity, not structural duplication. A successful migration should preserve contracts, transformations, routing rules, ordering requirements, error behavior, and essential business outcomes while allowing the target solution to adopt Azure-native identity, connectivity, observability, resiliency, deployment, and operating practices. Preserve what the integration must do. Refactor how it does it. Start by understanding what you have For many organizations, discovery is one of the most difficult parts of modernization. Documentation may be incomplete, original developers may no longer be available, and relationships between applications, endpoints, schemas, maps, pipelines, and custom components may be difficult to reconstruct. The Migration Agent scans the source project, catalogs supported artifacts, organizes related components into flow groups, and identifies dependencies and migration gaps. It can also generate architecture and message-flow visualizations for review before conversion begins. This discovery output becomes the foundation for migration sequencing, refactoring decisions, effort discussions, and risk management. Use AI to accelerate the work, not remove accountability The Migration Agent uses specialized GitHub Copilot agents for analysis, planning, and conversion. AI helps interpret source artifacts, propose mappings, create task plans, and generate baseline Logic Apps artifacts. Enterprise integration, however, requires more than plausible code generation. Human-in-the-loop checkpoints let teams review discovered flows, resolve missing dependencies, reshape the proposed architecture, approve conversion plans, and validate generated behavior before progressing. This combines the speed of AI assistance with the governance and technical review required for mission-critical integration. Modernize incrementally and reduce migration risk Large integration estates do not need a single big-bang program. The Migration Agent organizes work into logical flow groups so teams can refactor one business capability or integration path at a time. Prioritize workloads by business value, risk, complexity, or platform urgency. Validate target architecture and operating patterns with a representative first migration. Run phased cutovers and coexistence strategies when required. Apply reusable refactoring patterns, templates, and engineering standards to subsequent waves. A phased approach helps teams build experience with Azure Logic Apps while reducing migration risk and preserving delivery momentum. Bring your own tests and validate continuously Migration confidence depends on behavior, not structural similarity. The agent supports validation using source specifications, sample files, test cases, and customer-provided black-box tests. This helps compare expected inputs and outputs and identify semantic differences earlier. Generated artifacts are a baseline. Domain-specific transformations, error-handling behavior, performance characteristics, security controls, and edge cases still require customer and partner expertise. Built for BizTalk today and extensible for other platforms BizTalk Server 2016 and BizTalk Server 2020 are the first fully implemented source platforms. MuleSoft Anypoint support is represented as an in-progress built-in parser. The architecture is open and extensible so contributors can add parsers and platform-specific migration capabilities for other integration technologies. That extensibility is central to the vision. A common modernization workflow can help teams apply consistent governance, target patterns, refactoring practices, and validation across mixed integration estates. Why Azure Logic Apps Standard? Azure Logic Apps Standard provides a modern destination with a local project structure, Visual Studio Code development experience, source-control alignment, CI/CD support, stateful and stateless workflows, enterprise connectivity, and Azure and hybrid deployment options. Modernization is not about reproducing a legacy topology component by component. The target design should be optimized for Logic Apps Standard rather than constrained by the source architecture. The migration preserves valuable business logic while refactoring the implementation around modern practices for identity, networking, observability, reliability, deployment, and operations. What your team should still own The Migration Agent accelerates repeatable work, but it does not replace the decisions that define a production-ready integration platform. Responsibility Refactoring focus Target architecture Refactor application and workflow boundaries for Logic Apps Standard. Select reliability, networking, deployment, and supporting Azure patterns rather than copying the source topology. Semantic equivalence Validate contracts, mappings, transformations, business rules, error behavior, ordering, retries, and edge cases. Capability gaps Redesign source capabilities without direct equivalents using connectors, custom code, local functions, API Management, Service Bus, or other appropriate Azure patterns. Production hardening Implement identity, secrets management, security policies, monitoring, cost controls, performance testing, resiliency, and operational ownership. Cutover and coexistence Plan backlog reconciliation, dual-run periods, data consistency, partner coordination, rollback, and decommissioning. More mission critical features for Logic Apps Standard and Hybrid We are weeks away from shipping the following features, aimed at any customers in the Enterprise Application Integration space: HL7 In-App operations in general availability. MLLP Receive/Send In-App connector in Public Preview. Rules Engine In-App operation for XML facts in Public Preview. MSMQ In-App connector in Public Preview. Oracle DB In-App connector in Public Preview. Flat File generation In-App operations in Public Preview. Integration accounts support (Hybrid On premises). NMS In-App connector in Public Preview. Improvements to our EDI capabilities. BizTalk Mapper to Data Mapper Migration path What about other integration platforms? Yes—the Logic Apps Migration Agent is designed to be customizable so you can migrate from any integration platform to Logic Apps (not just BizTalk). The open architecture lets you plug in new discovery, analysis, and conversion skills for the source product you’re modernizing, while keeping the same stage-gated workflow and human-in-the-loop checkpoints. We provide guidance and examples to help you extend the agent for other platforms than BizTalk —so you can tailor mappings, transformation rules, and validation to your customer’s standards and target patterns in Logic Apps. Benefits Faster time to value with a guided process: A structured discovery→planning→conversion workflow reduces uncertainty and helps teams move from assessment to execution with clear checkpoints. Higher confidence migrations: Human-in-the-loop validation, artifacts generation, and black-box testing support mission‑critical correctness and governance. Customizable for your source platform and standards: Extend the agent with product-specific discovery and conversion steps, tailor mappings and transformation rules, and align outputs with your target Logic Apps patterns and engineering conventions. Open-source transparency and control: Review how the tool works end-to-end, validate what it produces, and adopt changes at your pace without waiting for a closed release cycle. Community-driven innovation: Benefit from contributions across Microsoft, partners, and customers—new adapters, mapping packs, and best practices can be shared and reused. Lower total migration cost: Automating repeatable tasks reduces manual effort while preserving the ability to invest partner expertise where it matters most (architecture, governance, reliability, and operations). Reusable accelerators for partners: Partners can create differentiated offerings by packaging templates, validation suites, CI/CD pipelines, and domain-specific patterns on top of the agent. An accelerator for customers and partners For customers, the Migration Agent provides a practical starting point and a consistent process for moving from assessment to a refactored implementation. For professional services organizations and system integrators, the agent augments delivery rather than replacing it. Automating inventory, analysis, baseline generation, and validation scaffolding allows experts to focus on architecture, governance, security, reliability, domain-specific transformation, DevOps, performance, cutover, and operating-model change. Because the project is open source, partners can contribute parsers or package reusable templates, mapping packs, test suites, CI/CD assets, and industry-specific modernization patterns. Review our public documentation here: https://learn.microsoft.com/en-us/azure/logic-apps/migration/migration-agent-overview How to get started Download VSCode and install the Logic Apps Migration Agent extension. Organize source projects and dependencies in a clear directory structure. Include project files, bindings, schemas, maps, pipelines, orchestrations, custom code, configuration, certificates or certificate references, and available documentation. Once you have all your artifacts ready, point the Migration Agent to the directory with all the artifacts. Review every migration stage. Confirm the discovered architecture, resolve missing dependencies, and refine the target design before authorizing conversion. Prepare a representative test environment. The workstation running Visual Studio Code must be able to reach the systems needed for local or end-to-end validation. Bring known inputs, expected outputs, specifications, and existing test cases whenever possible. These materials improve validation and reduce ambiguity. Treat the first migration as a reusable foundation. Capture architecture patterns, naming standards, deployment templates, observability practices, and lessons that can accelerate subsequent waves. Use Claude Opus 4.8 or higher. Make sure you increase the Maximum number of requests for the Copilot Chat as follows (we recommend changing the value from 60 to 1000) Check the following video for a demonstration on how the Agent works and let us know if you have any questions in the comments.BizTalk Server 2020 End-of-Sale Announcement
Executive Summary: BizTalk Server 2020 is the final release of BizTalk Server, and Microsoft expects sales of BizTalk Server 2020 and Host Integration Server 2020 to end March 31, 2027. Mainstream support for BizTalk Server 2020 continues through April 12, 2028, after which the product remains subject to Microsoft’s Fixed Lifecycle Policy. Microsoft also plans to offer eligible customers an optional, paid extended-mainstream support offering through April 10, 2030. Customers should begin planning their migration to Azure Logic Apps Standard or Azure Logic Apps Hybrid now, based on their deployment requirements. Closing a chapter Microsoft currently expects sales of BizTalk Server 2020 and Host Integration Server 2020 to end on March 31, 2027. Customers with existing valid licenses may continue to deploy and use the software in accordance with their licensing terms. Mainstream support for BizTalk Server 2020 continues through April 12, 2028. The end-of-sale date does not require customers to stop running licensed deployments, but customers should begin migration and licensing planning now because the extended-mainstream support offering described below remains subject to final eligibility, coverage, pricing, and purchasing terms. Microsoft plans to offer eligible BizTalk Server 2020 customers a paid, time-limited extended-mainstream support option from April 13, 2028, through April 10, 2030. The offering is intended to provide additional migration time, will have narrower coverage than the original mainstream-support phase, and will not add new product features. Eligibility, availability, supported components, servicing commitments, purchasing terms, and the official offering name will be published before enrollment opens. If you need to buy BizTalk Server 2020, or Host Integration Server 2020, you can do it until March 31, 2027. Recommended action Begin migrating your BizTalk Server workloads now, selecting Azure Logic Apps Standard or Azure Logic Apps Hybrid according to your organization’s hosting, networking, latency, data-residency, and operational requirements. Treat additional support coverage as contingency time rather than the default destination. Starting early gives teams time to inventory dependencies, redesign excluded capabilities, validate migrated solutions, and make commercial decisions before mainstream support ends. The Logic Apps Migration Agent can accelerate assessment and planning, convert supported artifacts, and assist with validation and deployment of refactored solutions on Azure Logic Apps Standard or Azure Logic Apps Hybrid. Extended-mainstream support scope Paid extended-mainstream support is planned as an optional, temporary bridge for eligible customers completing their migration. It is separate from the Extended Support phase available under Microsoft’s Fixed Lifecycle Policy and is expected to provide a different, narrower scope than the original mainstream-support phase. Microsoft expects the paid offering to run from April 13, 2028, through April 10, 2030. Certain BizTalk Server capabilities are expected to be excluded from the paid offering; the following list identifies the currently expected exclusions. Business Activity Monitoring (BAM) — The framework and tooling for capturing, tracking, and presenting near real-time business milestones, KPIs, and operational data from running BizTalk processes. Servicing, fixes, and updates for BAM components will not be provided under extended support. Enterprise Service Bus Toolkit (ESB Toolkit) — The libraries, itinerary services, and patterns that extend BizTalk with dynamic, itinerary-based routing, transformation, and centralized exception handling for service-oriented solutions. The ESB Toolkit will not receive servicing or support under extended support. Industry accelerators (SWIFT, HL7, and RosettaNet) — The domain-specific accelerators that provide schemas, pipelines, and validation for financial (SWIFT), healthcare (HL7), and supply-chain (RosettaNet) messaging standards. These accelerators will not receive servicing, schema updates, or support under extended support. Legacy enterprise adapters — The adapters that connect BizTalk to line-of-business and enterprise applications such as Siebel, PeopleSoft, TIBCO, and JD Edwards. These adapters will not receive servicing or support under extended support. Application Lifecycle Management (ALM) tooling and integrations — The BizTalk-specific tooling and integrations used for source control, automated build, deployment, and testing of BizTalk applications. These BizTalk-specific ALM components will not receive servicing or support under extended support. BizTalk Server images in Azure Marketplace — Microsoft currently expects to deprecate the BizTalk Server virtual-machine offer in Azure Marketplace. This affects the future availability of the Marketplace deployment image; it does not, by itself, make an otherwise eligible existing BizTalk Server 2020 deployment ineligible for paid extended-mainstream support. Microsoft will publish the effective date and guidance for existing virtual machines, new or replacement deployments, scaling, disaster recovery, customer-managed images, licensing, billing, patching, and support. New Visual Studio version support — Compatibility with Visual Studio versions newer than Visual Studio 2022 will not be added under extended support. Customers should review the Visual Studio 2022 lifecycle and support offering separately, because its coverage terms are independent of BizTalk Server extended support. Customers that depend on an excluded capability should prioritize the affected workloads in their migration plan. Use the Logic Apps Migration Agent to assess dependencies, inform target-architecture decisions, convert supported artifacts, and validate the migrated solution. Excluded BizTalk capabilities may require architectural redesign or manual implementation outside the agent. Customers are not required to purchase paid extended-mainstream support. Customers that do not enroll remain subject to Microsoft’s Fixed Lifecycle Policy and the applicable BizTalk Server 2020 lifecycle dates. The availability of technical support, non-security updates, security updates, and other services during the standard Extended Support phase depends on the policy requirements and the customer’s applicable support arrangement. The paid extended-mainstream support offering described here is an optional, separate offering for eligible customers that require additional coverage while completing their migration. After the end-of-sale date, customers that already hold valid BizTalk Server 2020 licenses may continue to deploy and use the software in accordance with the applicable licensing terms. Eligibility Paid extended mainstream support will be available to eligible customers with properly licensed BizTalk Server 2020 deployments. The final eligibility requirements will be provided in the published offering terms. Eligible products and versions: Paid extended-mainstream support is expected to be available for eligible deployments of BizTalk Server 2020 Enterprise, Standard, or Branch editions. Customers using Host Integration Server 2020 may also purchase the BizTalk Server paid extended-mainstream support offering to receive the applicable extended mainstream-support coverage for their HIS 2020 deployments, including customers that acquired BizTalk Server licences primarily to obtain HIS usage rights. BizTalk Server 2016, HIS 2016, and earlier versions will not be eligible. Azure Marketplace deployments: Existing BizTalk Server 2020 deployments created from eligible Azure Marketplace images are expected to qualify for paid extended-mainstream support, subject to the final offering terms. Customers must meet the applicable licensing, Software Assurance, supported-configuration, and complete-deployment coverage requirements. Microsoft will clarify how eligibility, licensed-core quantities, pricing, and purchasing apply when BizTalk Server software charges are included in the Azure Marketplace virtual-machine rate rather than acquired through a separate BizTalk Server licence agreement. Valid licenses: Customers are expected to maintain sufficient BizTalk Server licenses for each covered deployment in accordance with the applicable licensing model, including relevant core minimums, licensing of physical or virtual environments, and license-reassignment rules. Final extended-support licensing requirements will be stated in the published offering terms. Software Assurance: Active Software Assurance will be required at enrollment and throughout the applicable coverage period. Complete deployment coverage: Extended mainstream support must be purchased for all licensed cores in each enrolled deployment. Partial coverage of an enrolled production environment will not be permitted. Supported configuration: Covered environments must remain on a supported BizTalk Server 2020 configuration and meet published requirements for cumulative updates, operating systems, databases, and dependent components. Annual validation: Eligibility and licensed-core quantities will be confirmed for each coverage year. Customers must remain eligible to purchase Year 2 coverage. As part of the eligibility review, Microsoft may request licensing records, deployment inventories, configuration details, and migration-plan information. Complete requirements and enrollment instructions will be published before the offering becomes available. Purchasing details Paid extended mainstream support will be offered as annual coverage based on the licensed cores in each enrolled BizTalk Server 2020 deployment. Microsoft will publish final pricing, availability, enrollment dates, purchasing channels, and transaction terms before sales begin. Purchasing paid extended-mainstream support is optional and is not required for BizTalk Server 2020 to follow the Fixed Lifecycle Policy. Host Integration Server 2020: Eligible HIS 2020 customers will purchase coverage through the BizTalk Server paid extended-mainstream support offering. Customers that do not require HIS IBM Systems Network Architecture (SNA) capabilities should also evaluate Azure Logic Apps Standard or Azure Logic Apps Hybrid as a modernization alternative before purchasing additional support coverage. Azure Logic Apps Standard does not support SNA; customers that depend on HIS 2020 SNA capabilities must transition to Host Integration Server 2028. Coverage periods: Year 1 is expected to begin the next day mainstream support ends, on April 13, 2028, and continue through April 13, 2029. Year 2 is expected to run from April 14, 2029, through April 10, 2030. The final offering terms will confirm whether the boundary dates are inclusive and will specify the exact enrollment and coverage periods. Purchase sequence: Microsoft expects customers to purchase Year 1 coverage by April 11, 2028, to remain eligible to purchase Year 2 coverage. The final enrollment deadline and Year 2 eligibility conditions will be specified in the published offering terms. Price: Microsoft expects annual extended-mainstream support pricing to be 100% of the applicable BizTalk Server license cost under the customer's licensing agreement. Extended mainstream support is expected to be offered as an annual add-on for eligible BizTalk Server licenses. Final pricing and costs may vary by licensing agreement, geography, currency, available discounts, and the published offering terms. How to purchase: Customers will purchase coverage through an authorized Microsoft commercial licensing channel with support from their Microsoft account team or licensing partner. Separate support services: The annual extended-mainstream support fee is expected to cover only the servicing and support rights defined in the final offering terms. It will not include unlimited incident support, advisory services, migration delivery, solution implementation, or other professional services; customers may need a separate support plan or services agreement for those needs. Annual purchase: Coverage will not renew automatically. Customers must place a separate order and complete an eligibility review for each year. Support beyond April 10, 2030, is not planned. Contact your Microsoft account team or licensing partner to review eligible deployments, confirm licensed-core quantities, and obtain a quote when the offering becomes available. Discounts and incentives Microsoft plans to offer a targeted incentive for eligible existing BizTalk Server customers that are actively migrating to Azure Logic Apps Standard or Azure Logic Apps Hybrid. The incentive is designed to reduce near-term migration costs and support a faster move to the selected Logic Apps deployment model. It will not be automatic or broadly available; eligibility, approval, and final commercial terms must be confirmed by the customer’s Microsoft account team. Timing and important conditions Who can qualify: The incentive is intended exclusively for existing BizTalk Server 2020 customers approaching the announced BizTalk Server lifecycle milestones and actively migrating workloads to Azure Logic Apps Standard or Azure Logic Apps Hybrid. Redemption period: The incentive is expected to become available on August 31, 2026, and remain available through April 12, 2028, subject to publication of the program terms, eligibility approval, continued availability, and any applicable funding limits. Discount duration: The approved discount is expected to apply during the customer’s first qualifying Enterprise Agreement term after approval. The published program terms will define the eligible agreement types, qualifying start date, covered Azure services, discount duration, and treatment of renewals or agreement changes. Qualification: The incentive is subject to eligibility review and approval. Recommended action Ask your Microsoft account team or licensing partner to assess your migration scope, confirm which eligible migration path applies, and request consideration for the incentive. Migration support Contact your Microsoft account team to determine whether your organization is eligible for migration assistance delivered by the Azure Logic Apps product group or through another available migration-factory program. Program names, eligibility criteria, engagement scope, and availability will be confirmed through your account team. Migration options for Host Integration Server workloads Customers using Host Integration Server 2020 for application, data, messaging, or terminal integration—and who do not depend on HIS SNA capabilities—should evaluate Azure Logic Apps Standard or Azure Logic Apps Hybrid as a modernization target. Azure Logic Apps provides mainframe and midrange integration capabilities for scenarios involving IBM CICS, IMS, IBM i programs, DB2, IBM MQ, host files, and 3270 applications. Customers should assess each workload against the available connectors, supported protocols, networking, security, and operational requirements. Azure Logic Apps Standard does not support SNA. Customers running HIS 2020 workloads that depend on SNA capabilities must plan to transition to Host Integration Server 2028. Key dates March 31, 2027: Sales of BizTalk Server 2020 and Host Integration Server 2020 are expected to end. April 12, 2028: Mainstream support for BizTalk Server 2020 ends. April 13, 2028: BizTalk Server 2020 enters the Extended Support phase under Microsoft’s Fixed Lifecycle Policy, subject to the applicable policy requirements and lifecycle dates. April 13, 2028–April 10, 2030: Planned paid extended-mainstream support period for eligible BizTalk Server 2020 customers, subject to the final published offering terms. September 30, 2027: Host Integration Server 2028 is planned for release as a standalone product. Release timing is subject to change. July 7, 2030: Extended Support for Host Integration Server 2020 is currently scheduled to end. This date is separate from the planned BizTalk Server 2020 paid extended mainstream support period, which is expected to end April 10, 2030. Start your modernization journey with the Logic Apps Migration Agent. Use the agent to inventory and assess your BizTalk applications, prioritize integrations, build a phased migration plan, convert supported artifacts and workflows, and support validation, testing, and deployment to Azure Logic Apps Standard or Azure Logic Apps Hybrid. Excluded or unsupported BizTalk capabilities may require architectural redesign or manual implementation outside the agent. The agent’s AI-assisted, human-in-the-loop approach can accelerate modernization while your teams retain control of architecture and implementation decisions. Contact your Microsoft account team to discuss migration-assistance eligibility and commercial options. Learn more: BizTalk Server product lifecycle update | Bringing all your integration workloads to Logic Apps Standard | Fixed Lifecycle Policy – Extended SupportPower Azure SRE Agent with the tools it needs
What is the Azure SRE Agent Azure SRE Agent is an AI-powered service designed to reduce operational toil. Teams can use it to: Investigate incidents and identify probable causes. Automate health checks, compliance reviews, and other scheduled work. Answer questions such as “What changed before this service became degraded?” Propose remediations while allowing teams to require human approval. An effective investigation rarely depends on one source of information. An alert might originate in Azure Monitor, while deployment history lives in source control, telemetry stored in another observability platform, and incident records in a service-management tool. Without access to those systems, you must retrieve and transfer the information manually, adding context switching and slowing diagnosis. MCP servers can give SRE Agent tools to query telemetry, inspect deployments, retrieve database records, look up incidents, etc. SRE Agent provides native connection for some servers such as GitHub, Datadog, New Relic, and Splunk. Connector Namespace makes it easier to host additional remote MCP servers you want the agent to use. Removing remote MCP server hosting burden Connecting SRE Agent to an existing remote endpoint is straightforward. Hosting that endpoint yourself is not. You must deploy the server, provide secure HTTPS infrastructure, configure authentication, manage downstream credentials, scale the runtime, monitor its health, recover failed instances, and maintain it over time. These responsibilities are necessary, but the value is in the server’s tools not in operating another service. Azure Connector Namespace is a fully managed service for hosting connectors and MCP servers. You select the server you need and let the namespace handles the operational and maintenance tasks. The offering is currently in preview. See documentation for supported regions and other preview considerations. You’ll find a wide variety of servers in the Connector Namespace’s catalog. Some examples of useful servers for the SRE agent include: Database servers such as Azure SQL and Azure Cosmos DB Source control and CI/CD servers like GitLab Incident management servers like Jira and PagerDuty A note on what's currently in development: We're building “bring-your-own” server support, allowing you to supply your own server image while the namespace handles hosting and operations. Please keep an eye out for the blog post about this! Deploy server and connect it to SRE Agent The following example deploys the SQL MCP server in Connector Namespace and connects it to Azure SRE Agent. 1. Server deployment Prerequisite: Install the Azure Developer CLI (azd). Clone the sql-server-samples repo: git clone https://github.com/microsoft/sql-server-samples.git Navigate to the azure-sql-mcp sample cd sql-server-samples/samples/applications/azure-sql-mcp From the azure-sql-mcp folder, run the following to log into your Azure subscription and then deploy the server and related resources: azd auth login azd up The last command will prompt for the following before deployment: Prompt Suggested value Explanation Enter a unique environment name mcp-dev This name added as prefix to Azure resources created Select an Azure Subscription Pick your subscription Resources will deploy under this subscription Enter value for connectorNamespaceIdentityType UserAssigned User assigned identity is recommended as it’s not tied to resource lifecycle Enter value for deployerLoginName Enter your Azure subscription login email To give your identity access to the MCP server Enter value for the location Pick a supported region Supported regions: West Central US, Central US, East Asia, North Europe Once deployment finishes, copy the MCP endpoint for use later. It looks similar to: https://<app-name>.<region>.logic.azure.com/api/connectorGateways/123abc456defg7890/mcpServerConfigs/sql-mcp/mcp (Optional) Test deployed server in Visual Studio Code GitHub Copilot: Open command palette > search MCP: Add server > pick HTTP > enter MCP endpoint and server name > pick Local Workspace. Inside .vscode/mcp.json, click Start above server name, then allow authentication with Microsoft in the popup and log into Azure subscription account. 2. Configure MCP connector in SRE Agent Connector Namespace does not create the connection in SRE Agent. Add the server endpoint through SRE Agent’s existing MCP connection experience. Open the Azure SRE Agent portal On the left menu, go to Builder > Connectors, and select + Add connector Under Choose a connector, select the MCP tab, choose MCP server, and select Next Configure the connector: Field Value Name A descriptive name for the server Connection type Streamable-HTTP URI The hosted server endpoint from Connector Namespace Authentication method Managed identity (Selecting managed identity automatically creates an identity for the connector.) Azure AD token scope https://apihub.azure.com/.default Select Next. Before testing the connection, grant the managed identity access to the MCP server. 3. Authorize the managed identity Open the Azure portal, search for the managed identity by name. In the identity’s Overview page, click JSON View (top right) and copy the tenantId and principalId. The principal ID is also called the object ID. Open Connector Namespace portal and search for the deployed namespace. Inside the namespace, navigate to the MCP Connectors tab on the left, then select the SQL MCP server. Inside the MCP server, click Access Policies, then select Add Access Policy. Enter the tenant ID and principal ID, then select Create. 4. Test and finish the connection Return to Azure SRE Agent portal and select Test connection. After the test succeeds, select the server tools the agent should use. Select Add connector. Establishing the connection can take a minute. Select Refresh at the top of the connectors page until its status changes to Connected. The agent can now use the selected server tools in chat threads. The azd deployment from previous created and seeded a SQL database with sample blog post data, so you can ask something like: What are the top blog posts? For more details, see MCP connectors and tools in Azure SRE Agent. Focus on the server, not its infrastructure MCP servers can give Azure SRE Agent access to the additional systems it needs to investigate incidents and perform operational work effectively. However, operating every remote server yourself introduces infrastructure, security, and maintenance responsibilities that distract from that goal. Connector Namespace removes much of that friction. Your primary question becomes “Which MCP server do I want to host?” rather than “How will I deploy, secure, scale, monitor, and maintain it?” Once deployed, the hosted endpoint can be added to Azure SRE Agent through its existing MCP connection experience. That gives teams a straightforward path to extending the agent with more operational tools, without turning MCP server hosting into another platform they must build and run. Try Connector Namespace with Azure SRE Agent and share your feedback! Resources Azure SRE Agent Overview Set up an MCP connector in Azure SRE Agent Connector Namespace Overview Hosted MCP servers in Connector NamespaceOn 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.Microsoft BizTalk Server Product Lifecycle Update
For more than 25 years, Microsoft BizTalk Server has supported mission-critical integration workloads for organizations around the world. From business process automation and B2B messaging to connectivity across industries such as financial services, healthcare, manufacturing, and government, BizTalk Server has played a foundational role in enterprise integration strategies. To help customers plan confidently for the future, Microsoft is sharing an update to the BizTalk Server product lifecycle and long-term support timelines. BizTalk Server 2020 will be the final version of BizTalk Server. Guidance to support long-term planning for mission-critical workloads This announcement does not change existing support commitments. Customers can continue to rely on BizTalk Server for many years ahead, with a clear and predictable runway to plan modernization at a pace that aligns with their business and regulatory needs. Lifecycle Phase End Date What’s Included Mainstream Support April 11, 2028 Security + non-security updates and Customer Service & Support (CSS) support Extended Support April 9, 2030 CSS support, Security updates, and paid support for fixes (*) End of Support April 10, 2030 No further updates or support (*) Paid Extended Support will be available for BizTalk Server 2020 between April 2028 and April 2030 for customers requiring hotfixes for non-security updates. CSS will continue providing their typical support. BizTalk Server 2016 is already out of mainstream support, and we recommend those customers evaluate a direct modernization path to Azure Logic Apps. Continued Commitment to Enterprise Integration Microsoft remains fully committed to supporting mission-critical integration, including hybrid connectivity, future-ready orchestration, and B2B/EDI modernization. Azure Logic Apps, part of Azure Integration Services — which includes API Management, Service Bus, and Event Grid — delivers the comprehensive integration platform for the next decade of enterprise connectivity. Host Integration Server: Continued Support for Mainframe Workloads Host Integration Server (HIS) has long provided essential connectivity for organizations with mainframe and midrange systems. To ensure continued support for those workloads, Host Integration Server 2028 will ship as a standalone product with its own lifecycle, decoupled from BizTalk Server. This provides customers with more flexibility and a longer planning horizon. Recognizing Mainframe modernization customers might be looking to integrate with their mainframes from Azure, Microsoft provides Logic Apps connectors for mainframe and midrange systems, and we are keen on adding more connectors in this space. Let us know about your HIS plans, and if you require specific features for Mainframe and midranges integration from Logic Apps at: https://aka.ms/lamainframe Azure Logic Apps: The Successor to BizTalk Server Azure Logic Apps, part of Azure Integration Services, is the modern integration platform that carries forward what customers value in BizTalk while unlocking new innovation, scale, and intelligence. With 1,400+ out-of-box connectors supporting enterprise, SaaS, legacy, and mainframe systems, organizations can reuse existing BizTalk maps, schemas, rules, and custom code to accelerate modernization while preserving prior investments including B2B/EDI and healthcare transactions. Logic Apps delivers elastic scalability, enterprise-grade security and compliance, and built-in cost efficiency without the overhead of managing infrastructure. Modern DevOps tooling, Visual Studio Code support, and infrastructure-as-code (ARM/Bicep) ensure consistent, governed deployments with end-to-end observability using Azure Monitor and OpenTelemetry. Modernizing Logic Apps also unlocks agentic business processes, enabling AI-driven routing, predictive insights, and context-aware automation without redesigning existing integrations. Logic Apps adapts to business and regulatory needs, running fully managed in Azure, hybrid via Arc-enabled Kubernetes, or evaluated for air-gapped environments. Throughout this lifecycle transition, customers can continue to rely on the BizTalk investments they have made while moving toward a platform ready for the next decade of integration and AI-driven business. Charting Your Modernization Path Microsoft remains fully committed to supporting customers through this transition. We recognize that BizTalk systems support highly customized and mission-critical business operations. Modernization requires time, planning, and precision. We hope to provide: Proven guidance and recommended design patterns A growing ecosystem of tooling supporting artifact reuse Unified Support engagements for deep migration assistance A strong partner ecosystem specializing in BizTalk modernization Potential incentive programs to help facilitate migration for eligible customers (details forthcoming) Customers can take a phased approach — starting with new workloads while incrementally modernizing existing BizTalk deployments. We’re Here to Help Migration resources are available today: Overview: https://aka.ms/btmig Best practices: https://aka.ms/BizTalkServerMigrationResources Video series: https://aka.ms/btmigvideo Feature request survey: https://aka.ms/logicappsneeds Reactor session: Modernizing BizTalk: Accelerate Migration with Logic Apps - YouTube Migration Agent (Complete refactoring from BizTalk to Logic Apps): Bringing all your Integration workloads to Logic Apps Standard | Microsoft Community Hub We encourage customers to engage their Microsoft accounts team early to assess readiness, identify modernization opportunities, and explore assistance programs. Your Modernization Journey Starts Now BizTalk Server has played a foundational role in enterprise integration success for more than two decades. As you plan ahead, Microsoft is here to partner with you every step of the way, ensuring operational continuity today while unlocking innovation tomorrow. To begin your transition, please contact your Microsoft account team or visit our migration hub. Thank you for your continued trust in Microsoft and BizTalk Server. We look forward to partnering closely with you as you plan the future of your integration platforms. Frequently Asked Questions Do I need to migrate now? No. BizTalk Server 2020 is fully supported through April 11, 2028, with paid Extended Support available through April 9, 2030, for non-security hotfixes. CSS will continue providing their typical support. You have a long and predictable runway to plan your transition. Will there be a new BizTalk Server version? No. BizTalk Server 2020 is the final version of the product. What happens after April 9, 2030? BizTalk Server will reach End of Support, and security updates or technical assistance will no longer be provided. Workloads will continue running but without Microsoft servicing. Is paid support available past 2028? Yes. Paid extended support will be available through April 2030 for BizTalk Server 2020 customers looking for non-security hotfixes. CSS will continue to provide the typical support. What is the end of sale date for BizTalk Server? We will announce an end of sale date for BizTalk Server on July 2026. What about BizTalk Server 2016 or earlier versions? Those versions are already out of mainstream support. We strongly encourage moving directly to Logic Apps rather than upgrading to BizTalk Server 2020. Will Host Integration Server continue? Yes. Host Integration Server (HIS) 2028 will be released as a standalone product with its own lifecycle and support commitments. Can I reuse BizTalk Server artifacts in Logic Apps? Yes. Most of BizTalk maps, schemas, rules, assemblies, and custom code can be reused with minimal effort using Microsoft and partner migration tooling. We welcome feature requests here: https://aka.ms/logicappsneeds Does modernization require moving fully to the cloud? No. Logic Apps supports hybrid deployments for scenarios requiring local processing or regulatory compliance, and fully disconnected environments are under evaluation. More information of the Hybrid deployment model here: https://aka.ms/lahybrid. Does modernization unlock AI capabilities? Yes. Logic Apps enables AI-driven automations through Agent Loop, improving routing, decisioning, and operational intelligence. Where do I get planning support? Your Microsoft account team can assist with assessment and planning. Migration resources are also linked in this announcement to help you get started. Microsoft CorporationUse 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"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 library
