Logic Apps Aviators Newsletter - November 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month November 2026's Ace Aviator: Steef-Jan Wiggers Coöperatie VGZ What's your role and title? What are your responsibilities? I'm a Domain Architect Technology in the Business Change department at VGZ, one of the largest health insurers in the Netherlands. I'm responsible for defining architecture building blocks and target architectures. I also investigate which technologies can help us and what changes our IT landscape needs to support the IT capabilities VGZ requires. Can you give us some insights into your day-to-day activities and what a typical day in your role looks like? Each week starts on Monday with our week start, where I meet with peers on a range of architectural topics. From there, no two weeks are the same. I create target architectures for IT capabilities such as integration, cloud, artificial intelligence and, most recently, search. These building blocks describe the “what” and feed into solution architecture, which works out the “how”. Getting to a well-defined target architecture means talking every day with peers and stakeholders across the organisation. I also make time to explore new technology hands-on, to see whether it fits our needs. I share what I find internally in what we call Business Change colleges, knowledge sessions for colleagues. And I'm in frequent contact with Microsoft, both the local team in the Netherlands and the product groups in Redmond. What motivates and inspires you to be an active member of the Aviators/Microsoft community? I've worked in integration for over 20 years. I started with BizTalk Server and today I work with Azure Integration Services. Along the way I've designed, built and deployed many integration solutions, on-premises, hybrid and in the cloud. I've always enjoyed sharing what I learn with peers, through blogging, writing books, editing for InfoQ, and speaking at user groups and conferences such as Integrate and NIS. Sharing knowledge comes back to you many times over: it has given me great opportunities, and above all many friends in the community. 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? Stay curious, and don't wait until you feel like an expert to share what you know. Writing a blog post, giving a talk at a local user group, or just asking questions in the community speeds up your learning enormously and connects you with people who will help you grow. Also, learn the fundamentals well. Technologies change; integration went from BizTalk to Logic Apps. But patterns, principles and how you approach a problem last a whole career. What has helped you grow professionally? Curiosity about how things work. I learn by trying things out and building demos, and I read a lot: books, blogs, documentation. Attending, and later speaking at, user groups and conferences has been just as important. So has staying close to Microsoft, locally and with the product groups in Redmond. The conversations with peers and product teams have taught me as much as any technology. If you had a magic wand that could create a feature in Logic Apps, what would it be and why? A seamless, browser-based development experience with native GitHub integration. The designer in the browser offers the best experience for building Logic Apps, better than VS Code. But today, getting a workflow into source control means exporting it, working locally, and then pushing it. I'd love to do it all in the browser: design the Logic App, commit it straight to the repository, and let a pipeline deploy it to the other environments. That would bring the ease of the designer and proper DevOps practices together. News from our product group Introducing the Logic Apps local CLI: develop Standard workflows from your terminal Microsoft has introduced a public preview Azure CLI extension for local Logic Apps Standard development. It supports project creation, connector discovery, connection configuration, runtime management, workflow validation, and execution diagnostics from the terminal. Developers can invoke commands directly, automate them in scripts, or let coding agents use them with approval. The extension complements the visual designer and existing Azure resource-management commands rather than replacing them. An accompanying Copilot skill guides schema discovery, authentication choices, validation, and execution checks, helping teams ground development and review in observable tool results instead of assumptions. Hybrid Logic Apps - SQL as storage provider benchmarking This benchmark examines SQL Server storage behavior under a file-triggered Hybrid Logic Apps workload in a disconnected, single-node OpenShift environment. SQL Server 2025, file storage, and the cluster share one Windows host and backing disk. Two thirty-minute tests recorded no failed runs; the one-hour dashboard showed 45,821 successful executions. SQL averaged 1.83% of host CPU capacity, while storage contention and tail latency remained important scaling considerations. The article recommends dedicated storage as volumes grow and capacity planning based on peak and tail measurements, stressing that these results describe one workload rather than a general capacity guarantee. 🆕Orchestrate Foundry Prompt and Hosted Agents with Logic Apps Automation Logic Apps Automation can orchestrate Microsoft Foundry Prompt Agents and Hosted Agents as steps in business workflows. API calls, schedules, and connector events can trigger agents, with deterministic actions gathering inputs and validating or acting on outputs. The article distinguishes configured Prompt Agents from container-based Hosted Agents that support custom code and orchestration. Logic Apps provides branching, retries, timeouts, parallel execution, and run history around agent calls. It also outlines a migration path ahead of Foundry workflows retiring on December 1, 2026, helping teams move interactive agents into traceable, event-driven business processes. From Form to Action: A Governed, Event-Driven AI Intake Pipeline with Azure Integration Services This reference architecture turns document-heavy permit intake into governed, asynchronous processing with Azure Integration Services and Microsoft Foundry. API Management controls entry and model access, while Logic Apps validates, enriches, and routes submissions to Service Bus. An Azure Function uses Document Intelligence and a Foundry model before writing a case record and publishing an Event Grid event. A shared correlation ID connects intake, processing, and downstream notifications. The article emphasizes durable hand-off, explicit failure handling, controlled model consumption, and traceability, with an accompanying repository that supports offline exploration without an Azure subscription. 💲Announcing Free Grant and Pricing for Logic Apps Automation Microsoft has announced pricing and free grants for Logic Apps Automation, currently in public preview. Monthly allowances per Azure subscription include 108,000 workflow execution-seconds, 1 GB of data retention, 1,000 Standard and 500 Enterprise managed connector calls, knowledge storage, and AI usage. One managed environment is free only for the first sixty days, unlike the recurring monthly usage grants. Usage beyond the included limits is billed separately. The article explains how teams can experiment and run initial automations within those allowances, then plan paid usage as business process and AI orchestration workloads grow. News from our community Logic Apps Community Day 2026: Agenda and Speakers Announced Event by Ahmed Bayoumy and Sebastian Meyer The agenda and speaker lineup for Logic Apps Community Day 2026 are now published, with the event taking place on December 3, 2026. This free, online community event will stream live on YouTube and is open to attendees worldwide. Eight talks combine longer sessions and lightning talks, covering AI and automation, enterprise architecture, production operations, scalability, and BizTalk migration. Q&A slots between talks provide opportunities to engage with the speakers. The official event page includes the full agenda, speaker details, and an option to add the event to a calendar. Don't Rebuild Your Workflows Inside Agents: Calling Azure Logic Apps from Microsoft Foundry, Securely Post by Rob McKenna Enterprise agents can reuse reviewed business processes rather than duplicate workflow logic inside prompts or agent code. This article demonstrates a Microsoft Foundry agent invoking a Logic Apps workflow through an OpenAPI tool, using managed identity and Entra authorization instead of SAS keys. A synthetic prior-authorization scenario combines a lookup, business-day calculation, escalation, and notification before returning a plain-language response. The approach keeps business rules in the existing workflow while separating conversational interaction from execution, providing a concrete pattern for securely exposing established integrations as agent tools. When Liquid transform in Logic Apps doesn't Behave like Liquid: A subtle string to integer pitfall Post by Şahin Özdemir Generating a date ten years ahead exposes a subtle type-conversion problem in Logic Apps Liquid transformations. The underlying DotLiquid implementation can treat a formatted year as a string, producing concatenation rather than the expected arithmetic result. Common integer-conversion techniques do not reliably resolve the issue. The article demonstrates converting through a floating-point value with the Times: 1.0 filter and applying Round before completing the calculation. This practical example helps integration developers distinguish Liquid syntax from runtime-specific behavior and avoid prolonged debugging of seemingly simple transformation logic. Logic Apps Standard brings freedom Post by Mikael Sand Choosing between Logic Apps Consumption and Standard involves more than comparing per-action charges with a fixed runtime cost. This article argues that Standard allows integration design to focus on business requirements rather than minimizing transactions, particularly when built-in operations process large volumes of records. It describes greater cost predictability within runtime capacity while acknowledging additional infrastructure ownership and networking complexity. Capacity, connectivity, DNS, routing, and firewall configuration remain operational responsibilities. The comparison helps teams weigh architectural flexibility against management overhead when treating integration as a strategic platform capability. Logic Apps and AI Agents: Building Agentic Workflows on Azure Integration Services Post by Mirko Peters Agentic integration design requires choosing an appropriate platform owner as well as connecting a model to business systems. This guide compares Logic Apps with Power Automate, distinguishing Azure resource management, managed identities, infrastructure templates, and monitoring from maker-oriented environments and governance. It explains agent workflow concepts and describes tools as named collections of actions with clear responsibilities. Model configuration and pricing vary by hosting plan, and some capabilities remain in preview. The discussion helps architects separate ownership, tool design, and runtime considerations before building AI-driven business processes. Microsoft Fabric and Logic Apps Side by Side Video by Sebastian Meyer Connecting real-time analytics to operational workflows allows detected business events to initiate action rather than remain dashboard observations. This video demonstrates combining Microsoft Fabric Real-Time Intelligence with business processes built in Logic Apps. The accompanying post describes events arriving from coffee stores and handing relevant information to the integration platform through the Logic Apps Automation SKU. The example separates event detection on the data platform from process execution on the integration platform, illustrating how teams can connect these responsibilities without treating analytics and business automation as unrelated systems. Getting Started Logic App Standard in Azure Video by Stephen W. Thomas Moving locally developed workflows into Azure requires a configured hosting environment as well as a deployment step. This fourteen-minute walkthrough demonstrates creating a Logic Apps Standard environment and deploying a local project from Visual Studio Code. It covers the Workflow Service Plan, storage, application settings, portal-based workflow creation, and connection-string management. The accompanying post also highlights removing the unused hosting plan during demo cleanup to stop further charges. The tutorial gives developers a practical sequence for taking local integration work into the cloud while considering configuration and resource lifecycle. Azure Logic Apps Automation: A New Approach to Dynamic, AI-Powered Business Process Automation Post by Manoj Sethuraman Business processes involving unstructured information, changing rules, and frequent exceptions can be difficult to express as fully predefined workflows. This article introduces Logic Apps Automation as an adaptive approach combining contextual AI decisions, organizational knowledge, human involvement, and enterprise integrations. It outlines project boundaries for governance and isolation, deployable applications containing process assets, and executable workflows combining triggers and actions. The comparison with traditional deterministic automation helps architects consider where runtime flexibility is useful while retaining explicit boundaries around deployment, oversight, and integration responsibilities across business functions. 📈 Daily Exchange Rates, Zero Manual Effort: D365FO + Logic Apps Post by Anitha Eswaran Daily exchange-rate imports can become repetitive and error-prone when an SFTP folder retains both historical and newly delivered files. This article describes a Logic Apps integration that identifies current-day files before submitting them to Dynamics 365 Finance and Operations through an enqueue-based approach. A scheduled workflow starts after the expected delivery time, lists files with the built-in SFTP connector, and evaluates metadata to filter processing. The example demonstrates how selection and validation steps reduce repeated historical imports and unnecessary work while automating a recurring finance integration requirement. What's New with Logic Apps Automation Post by Sagar Sharma The NIS 2026 updates connect Logic Apps Automation capabilities with practical environment and subscription planning. This recap covers managed AI models, reusable templates, development-platform connectors, and orchestration of Foundry and managed agents. It separates agent construction and governance from workflow triggering and business-system integration. Pricing combines a managed-environment base fee, compute that scales to zero, and optional capabilities, alongside free allowances. The article also distinguishes announced features from roadmap items, helping integration architects assess operational ownership, environment counts, and experimentation costs before designing an automation platform. Coders, What's new with Low Code Logic Apps? Post by Sagar Sharma Integration developers need local build, test, debug, and deployment loops that work with source control and coding agents. This NIS recap examines the Logic Apps Standard SDK, which expresses workflows through typed C# and a fluent API, allowing compiler feedback to catch mistakes earlier. It also discusses the local CLI lifecycle and Connector Namespace as managed connectivity for applications and agents. The article frames these capabilities as complementary developer surfaces, helping teams combine low-code orchestration with familiar software-engineering practices while checking release details before relying on illustrative commands. BizTalk End of Support: Logic Apps Migration Agent, Hybrid and Microsoft Migration Incentives Post by Sagar Sharma Planning a BizTalk migration requires more than waiting for the support deadline or converting individual artifacts. This article reviews lifecycle considerations and introduces the AI-assisted Logic Apps Migration Agent for assessing, planning, converting, validating, and deploying workloads to Standard. Three Copilot agents share a five-stage pipeline, with human approval between stages. The discussion also covers map reuse, hybrid deployment, and migration incentives. It positions tooling as an accelerator rather than a replacement for architectural judgment, helping teams structure discovery and validation around the dependencies and business behavior of an existing integration estate.Hybrid Logic Apps - SQL as storage provider benchmarking
Key findings for technical decision makers Hybrid Logic Apps ran a high-volume, file-driven integration workload on deliberately modest on-premises hardware: one host shared by the cluster, file storage and SQL Server 2025. Across both 30-minute tests there were no failed runs, and the one-hour dashboard view showed 45,821 successful runs at a 100% success rate. The database was not a cost driver: SQL Server used an average of 1.83% of host CPU capacity. Most runs finished in about 4 seconds, with a longer tail for the slowest 1%. The factor that most affects scale is storage, not server count, because adding workflow instances does not add disk capacity. For planning, budget for dedicated storage for the database and files as volumes grow, size capacity on peak and tail response times rather than averages, and validate with your own workloads. These results are a baseline for one workload, not a product-wide capacity guarantee. A practical look at throughput, latency, reads, writes, and locks The primary goal of this exercise is to evaluate SQL read and write behavior and the time spent waiting for locks under integration load. Workflow throughput supplies the workload context; it is not a substitute for those database measurements. This is a mixed-workload observation, not an isolated SQL capacity test. In a 30-minute baseline, files were offered to an Azure Logic Apps workflow at approximately 100 files per second. SQL CPU usage remained low, while a substantial file backlog accumulated. The lesson is not that one component is necessarily slow. It is that a useful benchmark must connect offered load, completed throughput, latency, and waiting rather than treating any one metric as the answer. The SQL comparison tells a different story from workflow throughput alone: average workflow-state data-file write I/O latency rose from 12.958 to 38.652 ms, while accumulated instance-wide lock waiting remained near 1,470 task-seconds. Faster workflow completion did not mean that every SQL measurement improved. A repeat of the same 30-minute workload subsequently showed 3.87% higher successful throughput, 6.40% lower p95 execution latency, and 8.68% lower p99 execution latency, with no failed workflow runs in either measured window. Both measurements are retained below: the repeat was an observed improvement, not proof of a tuning change or a product-wide performance guarantee. The workflow The workflow snapshot shows the processing sequence used in the benchmark. The workflow is taken such that huge set of I/O operations are performed during the workflow executions to simulate the SQL benchmarking under high I/O operations. The workflow performs six steps: Detect a newly created file in a receiving folder. Insert a business record into SQL. Read the source file's contents. Create a copy in a destination folder. Delete the source file. Delete the destination copy. This is a synthetic processing-and-cleanup scenario, not an archival workflow: both test-file copies are removed on successful completion. A successful run means that the complete sequence finished, not just that the SQL insert succeeded. Infrastructure: OpenShift K8se cluster with single node, one shared disk The deployment topology is a hosted Windows machine running an on-premises, single-node OpenShift cluster in a Linux VM, with local SMB storage and SQL Server 2025 on the same Windows host. The SMB files, SQL data and transaction logs, and cluster VM storage all share the same host drive and backing disk. Different folders or virtual disks on that shared backing disk do not create independent I/O capacity. The workflow operates in a fully disconnected runtime environment: the execution and data paths shown remain local, without an external runtime-service dependency for this workflow. This documents the supplied runtime topology, not an independent network-isolation test or a claim about offline installation and management. Autoscaling adds workflow pods, not OpenShift nodes or additional disks. The configured 1-10 replicas therefore share the same single-node compute and storage resources. This layout matters when interpreting performance. File creation, reads, copies, and deletion can overlap with SQL reads, data writes, transaction-log writes, and cluster storage activity on the same disk. More pods can increase that shared I/O demand without increasing disk capacity. Storage delays can also lengthen transactions and the time locks remain held, but the topology alone does not establish that disk contention caused the measured blocking or throughput limit. How the baseline was measured The test offered small, 1 KiB files at a target rate of 100 files per second for 30 minutes. The existing workflow and database configuration were retained during the measurement; this was a baseline, not a tuned result. Measurements covered file publication, workflow starts and outcomes, execution duration, SQL request timing, SQL process resources, database-file I/O, and blocking. Existing autoscaling remained enabled, so this was not a fixed-replica benchmark. Observability also has a cost: these are instrumented results, not a claim of zero measurement overhead. SQL benchmark: reads, writes, and locking periods The database results below come from the two measured 30-minute exercises, not from the one-hour dashboard view later in this post. SQL counter snapshots bracket each exercise: approximately 1,801.16 seconds for the initial workflow-state observation and 1,801.74 seconds for the repeat. Business-data counter coverage is approximately 1,801.16 and 1,801.71 seconds. The workflow load-generation window itself is exactly 1,800 seconds. Evaluation Plain-language question What the saved measurements can answer Read How much information does SQL retrieve, and how long do disk reads take? Physical database-file read counts and average I/O latency; completed SQL request timing. Write How much information does SQL save, and how long do data and log writes take? Physical data-file and log-file write counts and average I/O latency; completed SQL request timing. Locking period How long does an operation wait for another operation, and how long does the owner hold its lock? Accumulated lock-wait time, waiting-task counts, and sampled blocking. Individual lock-hold durations were not recorded. Read and write I/O: volume and latency The two database roles are labeled workflow state and business data. Each row below describes a file-I/O operation, not an individual SQL statement. Database role / file I/O operation Initial count Repeat count Initial average ms/I/O Repeat average ms/I/O Workflow state / data Read 35,169 9,331 0.896 0.571 Workflow state / data Write 74,146 90,913 12.958 38.652 Workflow state / log Write 318,134 334,775 0.938 1.115 Business data / data Read 104 19 0.923 0.474 Business data / data Write 124 14 0.919 0.714 Business data / log Write 25,826 27,018 1.152 1.425 Average read I/O latency = read-stall milliseconds / read I/O count. Average write I/O latency = write-stall milliseconds / write I/O count. These are operation-weighted counter ratios, not averages of sample averages. The repeat performed fewer physical data reads and more workflow-state writes. Its average workflow-state data-file write latency was approximately three times the initial value. Workflow-state log writes also became slower on average. The small business-data file-I/O counts should not be treated as a stable disk-performance estimate. A read satisfied from memory need not cause a physical file read. Likewise, many row changes can be persisted together, and transaction-log writes are distinct from later data-page writes. Consequently, these counts are not SELECT counts, INSERT counts, or committed business-record counts. None of the file-I/O averages is the duration of an entire SQL statement or transaction. Completed SQL request timing SQL requests provide a separate view of elapsed server-side work. The trace selected events completed within each exact 30-minute window. Percentiles are approximate; requests still running at cutoff are excluded. Database role / request type Window Completed events Average ms p95 ms p99 ms Workflow state / remote call Initial 1,127,136 1.780 2.431 62.479 Workflow state / remote call Repeat 1,170,736 1.647 1.643 52.385 Business data / remote call Initial 81,114 0.960 1.354 14.487 Business data / remote call Repeat 84,220 1.041 1.225 15.503 Workflow state / SQL batch Initial 586 0.244 0.382 0.557 Workflow state / SQL batch Repeat 645 101.029 33.750 7,967.948 A remote call is a completed RPC event, not necessarily one statement. These request populations mix reads, writes, and supporting work; they do not establish separate SELECT-only or INSERT-only latency distributions. Batch events are shown separately rather than hidden inside the much larger remote-call population. Database-wide activity can include monitoring and dashboard requests, so this is not an application-only isolation test. The repeat improved workflow-state remote-call latency, but business-data p99 and batch latency worsened. There is no basis for saying that all SQL latency improved. Lock waiting: duration, concurrency, and observation period A lock hold belongs to the operation owning the lock: acquisition through release. A lock wait belongs to another operation waiting to obtain a conflicting lock. These are different periods; a waiting operation's duration does not reveal precisely how long the owner held the lock. Locking measurement Scope Initial Repeat Accumulated lock-wait time SQL instance 1,473.235 s 1,467.470 s Lock-waiting task count SQL instance 51,283 50,548 Wait-time / waiting-task counter ratio SQL instance 28.728 ms 29.031 ms Range/update coordination waits SQL instance 1,287.958 s 1,273.562 s Update coordination waits SQL instance 183.449 s 168.197 s Other lock waits SQL instance 1.828 s 25.711 s Peak sampled blocked requests Workflow-state database 16 20 Snapshots showing blocked requests Workflow-state database 85 / 353 78 / 354 Longest span of consecutive positive blocking snapshots Workflow-state database Approximately 15.2 s Approximately 10.2 s The cumulative lock counters are instance-wide and reported once, not added again for each database. Other activity on the instance can contribute. They count waiting SQL tasks, not unique transactions, locks, or workflow runs. The mean counter ratio is not a measured per-lock hold time or a lock-wait percentile. 1,473 accumulated wait-seconds does not mean the database was continuously blocked for 1,473 seconds. Concurrent tasks can wait at the same time. The totals cannot be divided by test duration and described as the percentage of the test spent blocked. The roughly five-second snapshots count requests blocked by another identified session. They do not record each request's wait type or lock lifetime. The longest positive-snapshot span means blocking was present at successive observations; different requests may have been involved, and blocking could have stopped between samples. It is not proof of one continuous blocking episode or one transaction holding a lock for that long. No blocked business-data requests were seen in the snapshots; brief blocking between samples remains possible. For write-related context, instance-wide waiting for transaction-log flushes accumulated 1,200.092 seconds initially and 1,390.289 seconds in the repeat. These are task-wait sums, not individual commit latency or additional time to add to workflow duration. What this does and does not establish The exercise establishes measured read/write I/O volume and average latency, mixed SQL request timing, and aggregate lock waiting with sampled blocking under the workflow workload. It does not establish isolated SQL read/write capacity, statement-specific read/write latency, exact blocking-episode lengths, or p50/p95/p99 lock-hold durations. One-hour dashboard results (Initial + repeat) These are actual values from the supplied dashboard with Last 1 hour visibly selected. This is a rolling dashboard observation, not a newly executed one-hour controlled load test. Measurement Dashboard result Selected observation period Last 1 hour Total runs displayed 45,821 Successful runs displayed 45,821 Failed runs displayed 0 Displayed successful count / 3,600 seconds 12.728 runs/second Average execution duration displayed 3.70 seconds Success rate displayed 100% Retry count No data Processing beyond the cutoff This supplied dashboard view spans a longer period than the 30-minute baseline. Processing continues after file generation stops. The displayed run total belongs to the dashboard's selected scope and aggregation. It is not the number of successful completions during the fixed measurement window, and it has not been reconciled to the exact benchmark cohort. The curve shows run counts over time, not a cumulative completion counter; its bucket size is not specified here, so the vertical values should not be read as runs per second. Latency: look beyond the average Successful workflow execution duration Result Average 4.11 seconds p50 Approximately 3.89 seconds p95 Approximately 6.20 seconds p99 Approximately 13.01 seconds Maximum 23.71 seconds These durations measure workflow execution after a run starts. They exclude time spent waiting in the receiving folder. As the backlog grows, a file's arrival-to-completion time can be much longer. Each point summarizes one minute. Workflow duration uses seconds; SQL request duration uses milliseconds. The SQL panels separate requests associated with workflow state from requests associated with business data, without exposing database identities. The first few minutes show higher workflow latency than much of the later window. The chart exposes this change but does not, by itself, establish its cause. The workflow chart includes successful runs completed by cutoff. SQL timing includes captured completed requests; requests still running at cutoff are not represented in those percentiles. Workflow bucket and whole-window comparison percentiles were computed from the observed completed runs; displayed values are rounded. SQL percentiles are approximate. SQL activity in the broader observation period These supplied SQL panels provide broader context, not additional fixed-window baseline results. SQL operations per second counts database work, not completed workflow runs: one workflow can require multiple SQL operations. The CPU line here is measured in milliseconds of SQL execution CPU time, not the percentage of host capacity shown below. Dashboard time ranges and aggregation differ from the baseline charts, so their averages and totals should not be substituted for the 30-minute measurements. SQL process measurement Result Average CPU, normalized to host capacity 1.83% Peak sampled CPU, normalized to host capacity 8.08% Physical memory at the first recorded sample Approximately 1.20 GiB Physical memory at the last recorded sample and peak Approximately 3.15 GiB These are instance-wide SQL process measurements, not workflow-container utilization or total machine utilization. CPU points represent roughly five-second interval averages, not instantaneous peaks. The dashed reference uses the reported full-window average; the recorded series ends slightly before cutoff and is not extrapolated. A system can have CPU headroom while work waits for storage, another transaction, a network response, or another part of the workflow. Aggregate CPU usage can also hide a narrower, serialized bottleneck. Configured scaling and application resources The deployment's configured scaling values were captured after the repeat. Application-configuration fingerprints matched before and after the test. Scaling setting Captured value Minimum replicas 1 Maximum replicas 10 Polling interval 30 seconds Configured cooldown 300 seconds Polling and cooldown values describe configuration, not guaranteed reaction times. Actual scaling also depends on controller decisions and stabilization. The dashboard's matching-pod count rises from about one to five, then steps down through four to three during the repeat. A later increase occurs after the measurement cutoff, while queued work continues processing. This panel counts matching pod records; it does not filter explicitly for readiness. It should not be interpreted as proof that every displayed pod was ready at every instant. Independent runtime checks found one ready replica before the repeat and three after it. The captured resource budget also distinguishes the application container from the entire pod: Resource scope, per replica CPU request CPU limit Memory request Memory limit Application container 0.425 cores 1 core 1,844 MiB 2 GiB Whole pod, including supporting containers 0.501 cores 1.5 cores 2 GiB 4.5 GiB Green represents usage; yellow represents the summed application-container limits. The chart's resource scope excludes supporting containers, so it is not the whole-pod or cluster resource budget. The CPU usage line is a five-minute rate expressed in cores. Memory usage is the containers' working set. As the number of matching application containers changes, their summed limits change too; this does not mean usage suddenly rose to the limit. These application metrics are not interchangeable with SQL process CPU percentages or SQL process physical memory. Aggregate headroom also does not exclude per-container throttling or uneven load distribution. Supplied latency dashboard This supplied panel shows p50 3.60 s, p95 5.47 s, and p99 10.5 s for its selected scope. Its time filter is not visible, so these values are not substituted for the fixed-window comparison above. Run and SQL trends beyond the repeat window This view extends beyond the 20:54:59 IST measurement cutoff and includes continued processing. Values are counts in the dashboard's time buckets, not a cumulative total or a documented runs-per-second rate. SQL duration and SQL CPU time here are in milliseconds. They are not workflow execution time or host CPU percentage. The dashboard aggregation covers a different scope from the verified 30-minute SQL measurements. How to use these results This is a baseline for one synthetic workflow, payload size, workload shape, and deployment. It is not a product-wide capacity limit, service-level guarantee, or comparison between deployment platforms. Workflow outcomes describe runs started within the measurement window and their status at cutoff. They are time-window totals, not a file-by-file correlation audit; concurrent executions of the same workflow can contribute. SQL process resources and wait measurements can include other activity on the same instance; individual SQL requests are not equivalent to workflow runs. For organizations that must keep integrations close to their data, whether for regulatory, data-residency or operational reasons, Hybrid Logic Apps brings the Logic Apps platform into their own datacenter. In this benchmark, the workflow ran fully disconnected on a single on-premises host, with SQL Server 2025 storing workflow state and no dependency on an external runtime service. The business value is straightforward. Sensitive data stays on site, workflow state lives in a database your team already operates and protects, capacity scales automatically within the hardware you own, and when demand spikes, work queues instead of failing. Teams also build on the same Logic Apps skills they use in Azure, rather than maintaining a separate integration stack for on-premises workloads. Recommendations Do not manually alter, truncate, drop, or selectively delete records from runtime-managed SQL tables. Partial changes can leave missing content, orphaned metadata, inconsistent run history, or state that affects retries and recovery. Use the deployment’s supported retention and cleanup mechanisms; any exceptional database maintenance should follow with a recoverable backup. Performance: Evaluate storage latency, CPU, memory, and blocking. Validate supported configuration changes through repeatable benchmarks rather than modifying internal tables or weakening transaction consistency. Please refer this for SQL server guidance Monitor and Tune for Performance - SQL Server | Microsoft Learn Give SQL independent I/O capacity from SMB and cluster VM storage. Increase CPU or memory when measurements justify it—not simply because throughput is low. Use supported availability groups or failover clustering for availability and recovery. These are not automatically a scale-out solution for writes. Follow Availability Group: Prerequisites, Restrictions, and Recommendations - SQL Server Always On | Microsoft Learn We executed the test using single node K8se cluster, for better use distribute workflow pods across independent worker hosts with adequate storage and networking. Scale incrementally and remeasure successful throughput, write latency, blocking, backlog, and recovery behavior while preserving runtime-managed tables.Logic Apps Aviators Newsletter - October 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month October 2026's Ace Aviator: Hicham Boutaleb & Azure Solution Architect @ 5-Nines Consulting What's your role and title? What are your responsibilities? I work as an Enterprise Integration Architect, helping organizations design, implement, and modernize integration platforms using Microsoft technologies. My responsibilities include defining architecture, leading technical delivery, supporting development teams, ensuring best practices around security and governance, and helping customers get the most value from Azure services such as Logic Apps, API Management, Service Bus, and Azure Functions. Can you give us some insights into your day-to-day activities and what a typical day in your role looks like? No two days are exactly the same, which is one of the things I enjoy most about my role. A typical day usually involves a mix of: - Designing integration and automation solutions. - Reviewing architectures and code with project teams. - Supporting customers in solving complex technical challenges. - Running workshops and knowledge-sharing sessions. - Evaluating new Azure capabilities and how they can benefit ongoing projects. - Collaborating with business stakeholders to translate requirements into scalable technical solutions. I also dedicate time to continuous learning because the cloud ecosystem evolves incredibly fast, and staying up to date is essential. What motivates and inspires you to be an active member of the Aviators/Microsoft community? The community is one of the best accelerators of professional growth. What motivates me most is the opportunity to learn from others while also giving back through sharing experiences, lessons learned, and practical solutions. I believe that technology is not just about tools—it's about people. The Microsoft community creates an environment where professionals can collaborate, innovate, and help each other succeed. Seeing someone solve a problem using knowledge I've shared is incredibly rewarding. 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? I would tell my younger self: Don't focus only on technology, focus on problem-solving and communication. Technical skills are important, but the ability to understand business challenges, communicate clearly, and work effectively with others often has an even greater impact on your career. I would also encourage people to: - Stay curious and never stop learning. - Build real projects rather than only collecting certifications. - Don't be afraid of failure—every mistake is an opportunity to learn. - Invest in your professional network early. The technology will change throughout your career, but adaptability and curiosity will always remain valuable. What has helped you grow professionally? Several factors have contributed to my growth: - Working on diverse and challenging projects. - Learning from experienced mentors and colleagues. - Being willing to step outside my comfort zone. - Participating in technical communities and events. - Maintaining a mindset of continuous improvement. Some of my biggest learning moments came from difficult projects where I had to solve problems I had never encountered before. Those experiences often teach more than success alone. If you had a magic wand that could create a feature in Logic Apps, what would it be and why? If I had a magic wand, I'd add an AI-powered end-to-end message tracking feature in Logic Apps that automatically follows a message across all workflows and Azure services it traverses. It would provide a single, intelligent view of the entire journey, making troubleshooting and root-cause analysis much faster and easier. News from our product group Your Certificate Renewed. Your Gateway Didn't Notice. Learn how certificate renewal can create outages when Azure Application Gateway does not detect an updated certificate in Azure Key Vault. The article explains certificate refresh behavior and practical steps for ensuring renewed certificates propagate reliably to dependent gateway infrastructure. How to Validate That Your BizTalk SB-Messaging Adapter Is Really Using AMQP Prepare BizTalk Server integrations for the retirement of the legacy Service Bus Messaging Protocol by confirming that the SB-Messaging adapter uses AMQP. This guide covers the required BizTalk Server 2020 hotfix and shows how to verify active AMQP-over-TLS connections on port 5671 across every relevant host and messaging configuration. Migrate Data Ingestion from Data Collector to Log Ingestion - Part 2 Continue migrating from the deprecated Data Collector API to the Azure Monitor Log Ingestion API by handling its smaller payload limit. The article demonstrates how to calculate and split large datasets into appropriately sized chunks in Azure Logic Apps so ingestion requests remain below the 1 MB limit. Bring Azure Logic Apps connectors into your .NET applications with the Azure Connectors SDK Explore the preview Azure Connectors SDK for calling Azure Logic Apps connectors directly from .NET applications without hosting a workflow. Strongly typed asynchronous clients, Azure Identity integration, and support for managed identities make it easier to connect application code to Microsoft and third-party services. Agentic Refactoring of Legacy Integration Workloads to Azure Logic Apps Standard See how agentic AI can accelerate the refactoring of legacy integration workloads into Azure Logic Apps Standard. This Microsoft Azure Developers video explores an AI-assisted modernization approach for analyzing existing solutions and moving them toward cloud-native workflows. Connect Azure Functions to SharePoint using Managed Connectors Learn how Azure Functions can connect to SharePoint using managed connectors. This Microsoft Azure Developers video demonstrates how connector capabilities simplify authentication and integration between function code and SharePoint. Connect SaaS & Enterprise Systems with Azure Functions This Microsoft Azure Developers video showcases how Azure Functions can use managed connectors for scalable, event-driven automation. It demonstrates integration with services such as SharePoint and Teams, highlighting how triggers and actions can reduce the need for manual polling and simplify authentication handling. The session walks through building practical workflows that connect SaaS and enterprise systems using Azure Functions. News from our community Logic Apps Community Day — 3 December 2026 Post by Ahmed Bayoumy Logic Apps Community Day returns on 3 December 2026 as a free, online event streamed live on YouTube. The program focuses on Logic Apps, the wider Azure integration stack, and AI patterns built on integration platforms. Organizers describe eight community speaking slots, combining longer sessions with lightning talks, and invite practitioners to submit examples, client cases, comparisons, or AI features. The event is intended for a worldwide audience and includes discussions, a published agenda, and opportunities for community members to share practical experience. Azure Logic Apps: Workflow Automation, Enterprise Integration, Connectors, B2B, Security, Networking, Monitoring, DevSecOps, Governance, and AI-Enable Post by Sanjeeve Kumar Gajadi This extensive guide presents Azure Logic Apps as an enterprise orchestration and integration layer rather than only a visual automation tool. It discusses Consumption and Standard hosting, triggers, actions, connectors, API Management, Service Bus, Event Grid, SAP, B2B protocols, managed identities, private networking, monitoring, reliability, DevOps, governance, and cost management. The article also considers AI-enabled orchestration and human approval patterns. Its central guidance is to design workflows around business processes, resilience, security, observability, and operational ownership while moving complex computation to suitable application services. Azure Logic Apps Handbook: 50 Expert Tips and Best Practices Post by Sandro Pereira Sandro Pereira introduces a free handbook containing 50 expert tips and best practices for Azure Logic Apps. The guide is aimed at architects, developers, integration specialists, DevOps engineers, and leaders working with cloud automation. Its coverage includes Logic Apps capabilities, practical use cases, workflow optimization, security, common pitfalls, and implementation strategies. The accompanying article explains that the handbook is intended to help readers design reliable, scalable, and maintainable workflows, and provides access to the downloadable resource through the linked publication. Build and Debug Logic Apps Standard Locally in VS Code Post by Stephen W. Thomas Stephen W. Thomas demonstrates how to build and debug Azure Logic Apps Standard workflows locally in Visual Studio Code without deploying resources to Azure. The walkthrough covers installing the extension, creating a stateful workflow with built-in operations, using local storage emulation, and sending a request from Postman. It also shows how to pause workflow execution at a breakpoint and inspect the results. The accompanying guide helps developers reproduce the setup and explore a practical local development loop while avoiding Azure charges during development and debugging. Azure API Management Premium v2 Workspaces and Dedicated Workspace Gateways in a Private Network Post by Şahin Özdemir Şahin Özdemir shares lessons from configuring Azure API Management Premium v2 workspaces and dedicated workspace gateways in a fully private network. The article covers Premium v2 virtual network integration, workspace isolation for multiple teams, internal-only workspace gateways, required Bicep resources and associations, and network security group rules. It also calls out deployment pitfalls and the less obvious Microsoft.ApiManagement/gateways/configConnections resource used to associate workspaces with gateways. The first part keeps API Management externally accessible while placing workspaces and their gateways inside the private network. Getting Started with Logic Apps Standard (in 2026) Video by Stephen W. Thomas Stephen W. Thomas shows how to set up Azure Logic Apps Standard locally in Visual Studio Code in under five minutes with no Azure charges. The updated installation brings in the Azure Functions runtime, Azure tooling, C# support, and storage emulators. The video creates a local workspace using built-in connectors, starts the workflow with F5, copies its callable URL, and sends a request from Postman. It also demonstrates breakpoints, debugger variables, action inputs, and stepping into custom in-process C# code for a complete local development experience.How to Validate That Your BizTalk SB-Messaging Adapter Is Really Using AMQP
On September 30, 2026, Azure Service Bus stops accepting the Service Bus Messaging Protocol (SBMP) — the protocol the BizTalk SB-Messaging adapter has always used. The failure mode is not a warning in a log file; it is a refused connection. To keep those integrations running, a BizTalk Server 2020 hotfix adds a new Azure.Messaging.ServiceBus AMQP implementation to the adapter in place of the legacy SBMP path. This post walks through how to validate the hotfix was successfully deployed and is using AMQP and not SBMP. Required baseline: BizTalk Server 2020 with Cumulative Update 6 or Cumulative Update 7 installed, plus the SB-Messaging AMQP hotfix — KB5091379, obtained by opening a Microsoft support case. The hotfix is not offered through Windows Update or the regular CU download, and it will not install on a CU5 or earlier baseline. Every node in the BizTalk group needs it. A multi-server group will happily run the affected host instance on an unpatched node, and your test may land on the one server where the fix is not active. Patch and restart host instances everywhere, then record the edition, CU level, hotfix number, and component build per server. Hotfix location: https://1drv.ms/f/c/cac4b5f5988b8228/IgCrzn_KTaZ8T5tuKmcdPgXxARuOLcGHDhxVLgeysj44GWE?e=w5AcpM Once the baseline is confirmed, test in a non-production environment that reproduces production topology, authentication, and the full network path — proxy, firewall, private endpoint, and DNS. And list every materially different configuration you intend to validate: each send port and receive location, queue, topic, and subscription usage, 32-bit versus 64-bit hosts, and features such as sessions, ordered delivery, or transactions. A green result on one port does not validate the others. Method 1: Verify the active connection on port 5671 (recommended) The adapter selects AMQP over TCP, and Azure Service Bus uses TCP port 5671 for AMQP over TLS. Correlating an established 5671 connection with the correct BTSNTSvc or BTSNTSvc64 process demonstrates that the BizTalk host is using the AMQP transport. Run elevated PowerShell while the receive location is enabled and actively polling: $hostProcesses = Get-Process BTSNTSvc, BTSNTSvc64 -ErrorAction SilentlyContinue Get-NetTCPConnection -State Established -RemotePort 5671 | Where-Object OwningProcess -in $hostProcesses.Id | ForEach-Object { $process = Get-Process -Id $_.OwningProcess [pscustomobject]@{ Process = $process.ProcessName ProcessId = $_.OwningProcess LocalAddress = $_.LocalAddress LocalPort = $_.LocalPort RemoteAddress = $_.RemoteAddress RemotePort = $_.RemotePort State = $_.State } } Expected result: Process is BTSNTSvc or BTSNTSvc64. Remote port is 5671. State is Established. The remote address resolves to or corresponds to the Service Bus namespace. What an empty result means: not much, on its own. An empty result is inconclusive, not a failure. Confirm the port or receive location is enabled, the host instance is running, traffic is actually flowing during the check, and that DNS, firewall, or private endpoint rules permit the connection — then repeat. One important exception: if your environment routes AMQP over WebSockets on TCP 443, you should not expect a 5671 connection at all. In that case skip to Method 2. Method 2: Capture adapter traces When the connection view is unavailable or ambiguous, the trace is the more definitive answer, because it shows which code path executed rather than which socket happened to be open. BizTalk adapter tracing uses ETW through BT.Trace.Tracer, and entries containing [SBMessaging-AMQP] confirm that the new AMQP-specific implementation executed. Start BizTalk adapter tracing immediately before the test — not hours earlier. Send or receive a single, uniquely identifiable test message through the target port or receive location. Stop tracing as soon as the message completes. Search the captured output for [SBMessaging-AMQP] entries inside the test window, and match them to the host instance and configuration you were exercising. Method 3: Block the legacy SBMP ports Methods 3 and 4 are corroborating tests, not proof, and belong in an isolated environment. Legacy SBMP commonly uses TCP ports 9350 through 9354. If the isolated AMQP workload continues to operate while those ports are blocked and TCP 5671 remains available, the result corroborates that the workload does not depend on SBMP. Record the original firewall rules before you start and restore them immediately afterwards — this test has a real blast radius if it escapes the test subnet. Method 4: Large message functional test In Basic and Standard tiers, the maximum message size is 256 KB, regardless of SDK or protocol, so this test does not apply there. In Premium, the legacy SBMP path supports messages only up to 1 MB, whereas AMQP supports larger messages up to the entity’s configured maximum of 100 MB. Successfully processing a Premium message larger than 1 MB therefore provides supplementary evidence that the adapter is using AMQP. Read a failure carefully: entity limits, timeouts, and pipeline constraints all produce the same symptom, so a failed large-message test is not by itself evidence that the hotfix did not take. Verify payload integrity and the event log, then remove the test message and restore any temporary entity settings. Do not stop at the protocol Confirming that AMQP is in use answers the transport question. It does not answer whether your solution still behaves the same way. AMQP and SBMP differ in a handful of behavioural details, so before you call the validation complete, run the scenarios your integrations depend on and compare against a pre-change baseline: Send and receive across each representative queue, topic, and subscription path, checking message body and application-property fidelity. Peek-lock completion, abandon, defer, dead-letter, and retry behaviour, plus sessions, ordering, transactions, and duplicate detection where you use them. Authentication renewal, and recovery after a host instance restart or a brief network interruption. Throughput and latency within your accepted baseline, with no new event log errors, suspended instances, duplicates, or lost messages.Logic Apps Aviators Newsletter - September 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month September 2026's Ace Aviator: Parth Talaviya What's your role and title? What are your responsibilities? AI-Powered Azure/.NET Solution Architect I work as an Azure/.NET Solution Architect, combining technical leadership with building a Microsoft-focused boutique company. My work mainly revolves around application modernization and migration, cloud architecture, integrations, and team leadership. I also stay hands-on with development, architecture reviews, production troubleshooting, and mentoring developers. Can you give us some insights into your day-to-day activities and what a typical day in your role looks like? My day usually starts with thinking about how we can add more value to our clients' businesses. It includes reviewing project priorities, solving technical challenges, discussing architecture, supporting developers, and collaborating with stakeholders. I mainly work across .NET, Azure, APIs, integrations, DevOps, and AI automation, so every day brings something new to learn and solve. What motivates and inspires you to be an active member of the Aviators/Microsoft community? What really motivates me is how active and supportive the Microsoft community is. People are genuinely willing to help each other, share experiences, and solve problems together. Being able to use my own experience to help someone overcome a challenge genuinely makes my day, while learning from others keeps me motivated to continuously improve. 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. In technology, especially when you are stuck on a very specific problem, it can sometimes feel that way. Asking questions, learning from the community, and collaborating with others can make a huge difference. I would also say: embrace AI early, but use it wisely. Don’t use AI only to generate code. Use it to understand concepts, challenge your thinking, explore better approaches, review your work, and become a better problem-solver. What has helped you grow professionally? Continuous learning and solving real-world challenges have helped me grow the most. Working on legacy modernization, cloud architecture, large-scale data systems, automation, and AI has taught me to think beyond writing code and understand the broader business impact. Being part of a strong technical community has also helped significantly. Whenever you are stuck, there is often someone who has faced a similar challenge and is willing to share their experience. If you had a magic wand that could create a feature in Logic Apps, what would it be and why? I would create an AI-powered Copilot troubleshooting and self-healing assistant for Logic Apps. It could analyze failed workflows, understand the execution context, identify the likely root cause, suggest a fix, and provide safe recovery options. For complex integrations, this could save significant troubleshooting time and allow developers to focus more on building solutions rather than spending hours finding where something went wrong. News from our product group Use connectors with Managed Identity in the Logic Apps Standard extension Managed Identity is Azure's built-in way to authenticate to Microsoft Entra-protected resources without storing credentials, secrets, or connection strings. Deployed Logic Apps have supported it for some time, and this post explains connector support in the Logic Apps Standard extension. Introducing dependency telemetry in Application Insights for Azure API Management policies Running API platforms at scale requires both handling load and understanding where inefficiencies occur. This post introduces dependency telemetry in Application Insights for Azure API Management policies to help teams identify performance bottlenecks. Power Azure SRE Agent with the tools it needs Azure SRE Agent is an AI-powered service designed to reduce operational toil. Teams can use it to investigate incidents, identify probable causes, and automate health-related operational work using connected tools. Give your Copilot agents real tools, without hand-wiring MCP GitHub Copilot coding agents can work independently on branches, but some tasks require access to external systems. This post shows how to equip agents with real tools without manually wiring Model Context Protocol integrations. Zonal redundancy in API management Standard v2 APIs power modern mobile experiences, microservices, AI-driven applications, and business-critical integrations. This post explains zonal redundancy in Azure API Management Standard v2 for improving resilience as customers modernize their API platforms. BizTalk Server 2020 End-of-Sale Announcement Microsoft announces that BizTalk Server 2020 and Host Integration Server 2020 sales are expected to end on March 31, 2027. Existing licensed deployments can continue to be used, while mainstream support for BizTalk Server 2020 is scheduled through April 12, 2028. An optional paid extended-mainstream support offering is planned for eligible customers through April 10, 2030, with final terms to be published later. The post recommends beginning migration planning now, evaluating Azure Logic Apps Standard or Azure Logic Apps Hybrid, inventorying dependencies, and using the Logic Apps Migration Agent to assess and convert supported workloads. Logic App Storage Inspector Logic App Storage Inspector is a read-only Kudu site extension for examining storage used by an Azure Logic App Standard application. It supports searching workflow action and trigger history by workflow, date, or text, with results exportable as CSV or JSON. Users can browse and compare workflow-definition versions, review table and queue information, and monitor health indicators and refresh status. The extension isolates access to the current Logic App site, uses asynchronous paged operations for large storage accounts, and can be installed from Kudu Site Extensions. News from our community Azure Logic Apps Automation – A Practical Infrastructure Lab with Agentic Remediation Post by João Paulo Costa João Paulo Costa tests Azure Logic Apps Automation through an after-hours virtual-machine remediation lab. The workflow uses an agent to inspect VM metadata, tags, and runtime state, then apply guardrails before deciding whether to deallocate the resource, leave it unchanged, or request review. The article contrasts agentic decision-making with deterministic workflows, documents tool and connector choices, and examines preview limitations such as runtime-state retrieval and managed-identity support. It also emphasizes constrained permissions, explicit policies, verification after actions, and negative testing for production, exemptions, missing ownership, and disabled remediation. Agentic Integration: Non-Deterministic Experience, Solid Core Post by Massimo Crippa Massimo Crippa examines whether agentic capabilities make enterprise integration non-deterministic. He separates an agent’s variable decision-making from the predictable integration layer that executes selected capabilities. The article highlights durable messaging, reliable contracts, idempotency, transactional boundaries, retries, compensation, governance, and observability as continuing requirements. It presents tools as the boundary between reasoning and execution: agents determine what should happen, while integration platforms control how operations are performed safely. Azure Logic Apps is positioned as both a deterministic integration foundation and a platform that can expose governed capabilities to emerging agentic experiences. Build AI Agents in Azure Logic Apps (Conversational + Autonomous) Video by Rafsan Huseynov Rafsan Huseynov presents a video on building conversational and autonomous AI agents with Azure Logic Apps. The session describes Logic Apps as more than a background integration layer, covering orchestration, managed identities, agent loops, and the use of workflows as MCP tools. Demonstrations explore connections with Document Intelligence, Blob Storage, Microsoft Foundry, and Copilot Studio workflows, alongside conversational and autonomous agent patterns. The video also introduces a separate low-code automation experience with scoped permissions, while noting that the demonstrations use synthetic data and that the experience remains in preview. BizTalk to Logic Apps migration (three things, everyone gets wrong) Post by Brajesh Sinha Brajesh Sinha explains why simple counts of BizTalk orchestrations and maps produce unreliable Logic Apps migration estimates. One orchestration can fan out into several Azure resources, supposedly simple maps may hide substantial transformation complexity, and operational requirements are often omitted from statements of work. The article highlights the architecture, mapping, and production-readiness effort that teams frequently underestimate. It encourages migration planners to assess actual behavior and dependencies rather than relying on inventory totals, helping create more realistic timelines, scope, and delivery expectations. Hybrid Logic Apps on RKE2: a self-managed cluster with MetalLB Post by Sonny Gillissen Sonny Gillissen demonstrates how to run Azure Logic Apps Hybrid on a self-managed RKE2 Kubernetes cluster. Because RKE2 does not include a native load balancer, the walkthrough uses MetalLB to assign the ingress IP required by the deployment. It covers creating the cluster, configuring networking, connecting the environment to Azure Arc, and handling the platform-specific details needed for Logic Apps. The article provides a practical alternative for teams evaluating hybrid integration workloads outside managed Kubernetes services, extending earlier guidance for OpenShift environments. An Introduction to Logic Apps Standard SDK Video by Marcel Medina Marcel Medina shares a Coding Night ANZ recording introducing the Logic Apps Standard SDK. The session shows how the SDK brings a modern, code-first .NET development experience to Azure Logic Apps while retaining the platform’s connectors, triggers, monitoring, and managed runtime. It is aimed at developers who want familiar tooling and stronger source-driven workflow development without giving up managed integration capabilities. The post also thanks the community for its questions and participation and provides the complete session recording for anyone who missed the live event. Managed Identity in Logic Apps Standard: A Zero Trust Read Post by Steef-Jan Wiggers Steef-Jan Wiggers examines new Managed Identity support for connectors in the Logic Apps Standard local development experience. Developers can now use a consistent authentication model from development through production instead of swapping connection strings before deployment, removing a common source of unmanaged secrets. The article frames this improvement through Zero Trust while stressing that authentication alone does not replace disciplined RBAC. A working azd sample demonstrates the setup and highlights a critical application setting whose absence causes the otherwise correctly configured connection, access policy, and role assignment to fail.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 Support
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.Logic Apps Aviators Newsletter - June 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month June 2026's Ace Aviator: Florian De Langhe LinkedIn: https://www.linkedin.com/in/floriandelanghe/ What's your role and title? What are your responsibilities? Lead Expert/Team Lead for the Microsoft Integration team at delaware. I have a wide range of responsibilities: - People management - Resource planning - Design and operate our integration solutions at our customers, what we brand as "SmartLink". Next to this, as many of us, I follow the latest AI news closely to keep up to date and try to stay ahead of the curve. Can you give us some insights into your day-to-day activities? I wear many hats so no two days look the same. That is also what keeps it interesting. A typical day starts with reviewing resource planning across our active projects, followed by a technical design review for a new integration. Sprinkle some one-on-one coaching conversations and research into new technologies/features and you have my day. The balance between People leadership and hands-on technical work is what I enjoy most. What motivates and inspires you to be an active member of the Aviators/Microsoft community? I started out being an active member on the Microsoft Logic App forum 10 years ago. I remember going back and forth with Wagner through the forum posts trying to solve questions. Good times. Integration is one of those disciplines where you're constantly connecting systems, teams, and ideas. What motivates me is seeing how members of our community across different companies and countries solve similar problems in completely different ways. The Aviators community has that right mix of deep technical knowledge and willingness to help each other out. Since discovering Integration and the Microsoft community, I basically never left. Looking back, what advice do you wish you had been given earlier? Document everything and treat documentation as a deliverable, not an afterthought. Early in my career I saw documentation as the boring part that you do after the development work. Now I see it as the leverage point. A well-written design document doesn't just help the next person understand what you built, it compounds. It feeds code generation, easier onboarding of new members and validation with your customers on what and how to build it. What has helped you grow professionally? Two things: 1) Always challenge yourself and your implementations; everything can be better, so I am always pushing myself to keep learning, stay up to date, and think about every idea/solution posted in this community—how it could improve my way of thinking or solutions that I am building/have built. 2) Focus on understanding the integration concepts and patterns. At the end of the day everything is a pattern; it is how you implement where we make the difference. So knowing the base layer itself helps a lot when building integration solutions. If you had a magic wand that could create a feature in Logic Apps, what would it be? To be able to control scaling of the workflow service plans more fine grained. Being able to control this would unlock a lot of use cases, especially for the combination of Logic Apps and Service Bus concurrency and throughput. News from our product group Write Logic Apps in C#: introducing the Logic Apps Standard SDK This article introduces the Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk), a code-first way to define Logic Apps Standard workflows in C#. Developers compose workflows using a fluent builder with strongly typed triggers and actions, including both built-in and managed connector operations. The SDK preserves the existing runtime, connectors, monitoring, and run history while changing only the authoring experience. It supports control flow constructs, custom C# code steps, and run-after conditions for fault handling. Guidance covers getting started in VS Code, project layout, local F5 execution, and preview limitations such as no service provider connectors and work-in-progress managed identity support. New AI gateway capabilities in Azure API Management Azure API Management expands its AI gateway with a Unified Model API (preview) that lets clients use a single OpenAI-style format across providers, plus model aliases and discovery. GA updates include support for Anthropic and Google Vertex AI and content safety for MCP and Agent-to-Agent (A2A) traffic. Token observability now tracks cached, reasoning, and thinking tokens in Application Insights. Foundry import adds Anthropic API operations. A2A APIs reach GA with richer diagnostics and availability in classic tiers. Together, these features standardize governance, security, and observability for multi-model, multi-protocol AI applications. 🎉 Automation just became a team sport. Meet Azure Logic Apps Automation. Azure Logic Apps Automation (public preview) is a new SKU that delivers a managed, SaaS-like experience for building and running workflow automations. It keeps the enterprise-grade Logic Apps engine while simplifying onboarding, collaboration, and governance with projects and applications, flexible permissions, and policy inheritance. The experience is AI-native with natural language authoring, first-class agents, tools via MCP, and managed sandboxes. It introduces a modern designer, draft mode, live run history, JavaScript expressions, elastic scale to zero, and knowledge-as-a-service integration—aimed at helping teams prototype quickly and operate securely at scale. 📢 Announcing Knowledge as a Service for Azure Logic Apps Knowledge as a Service (public preview) provides a managed knowledge layer for Logic Apps that turns documents into a ready-to-use knowledge base without building a custom RAG pipeline. The service handles ingestion (parsing, chunking, embeddings) and retrieval (query rewriting, semantic search, ranking) and integrates with agentic workflows in Logic Apps Standard and the Automation SKU. On Standard, teams bring their own vector store and models; on Automation, the platform hosts them on behalf of the user. It supports Entra authentication and focuses on secure, grounded responses for agents and workflows. Better Together: Build Agents in Microsoft Foundry, Automate them with Azure Logic Apps This post outlines a combined stack for agentic applications: Microsoft Foundry for building and hosting agents, and Azure Logic Apps for invoking and orchestrating them. New capabilities let teams create or select Foundry agents directly from the Logic Apps designer, pair any trigger with an agent for autonomous execution, and expose 1,400+ Logic Apps connectors and entire workflows as agent tools. The approach enables agents to act across systems, handle long-running processes, and integrate with enterprise events, making deterministic workflows and AI-driven reasoning work together in production. What's new in Azure API Management at Microsoft Build 2026 This roundup covers Build 2026 updates for API Management and API Center: GA for agent registration, assessment, and Git sync in API Center, plus a data plane MCP server for enterprise discovery. API Management adds GA support for JSON‑RPC agent‑to‑agent (A2A) APIs and extends content safety controls to MCP and A2A flows. Unified Model API enters preview to standardize client integration across model providers, and AI Gateway expands to Anthropic and Vertex AI with broader token metrics. Platform enhancements include multi‑domain and wildcard custom hostnames in v2 tiers and workspace support on the built‑in gateway. Azure Connector Namespaces: managed integration for any Azure compute Azure Connector Namespace (preview) offers a fully managed integration layer that brings the Logic Apps connector ecosystem to any Azure or self‑hosted compute without requiring a workflow engine. Apps call strongly typed SDKs for C#, Node.js, or Python to invoke actions and subscribe to triggers, while the namespace handles auth, token rotation, retries, throttling, and webhook delivery. It also projects connectors as MCP servers for agents, and supports hosted MCP servers like Playwright and Azure SQL. The post details building blocks, scenarios, security, governance, and preview limitations. What's new in Azure Logic Apps at Microsoft Build 2026 This Build 2026 overview highlights Logic Apps Automation (public preview), GA for the Logic Apps MCP Server to expose workflows as MCP tools, direct invocation of Microsoft Foundry agents from Logic Apps, Knowledge as a Service, and code‑first development with the Logic Apps Standard SDK (Codeful Workflows). It also introduces a Migration Agent to help modernize from legacy platforms. The theme is making enterprise‑grade automation more accessible while preserving governance, reliability, and operational controls for production use. Hosted MCP Servers in Connector Namespace (Preview) Hosted MCP servers in Connector Namespace let teams deploy managed, enterprise‑ready MCP servers from a curated catalog in minutes. The platform handles deployment, scaling, authentication (inbound with Entra ID, outbound with managed identity or on‑behalf‑of), availability, and observability via Application Insights. Preview servers include Playwright for browser automation and Azure SQL via Data API Builder, enabling agents to use reliable tools without the overhead of self‑hosting. The post explains setup, benefits over self‑hosted servers, and areas of ongoing investment like catalog expansion and VNet support. MCP Test Console and Git Repository synch in Azure API Center Azure API Center adds a built‑in MCP Test Console in the developer portal and Git repository synchronization for MCP servers and other assets. Developers can validate MCP tools interactively on the Documentation tab and browse server tiles with endpoints and schemas. Git sync keeps the API Center inventory aligned with source‑controlled definitions, with secure access via Key Vault and managed identity. Together, these additions streamline discovery, testing, and governance of MCP assets across the enterprise. Bringing all your Integration workloads to Logic Apps Standard This post outlines Microsoft’s guided path for moving enterprise integration workloads—especially BizTalk—to Azure Logic Apps Standard. It introduces the open-source Logic Apps Migration Agent, which delivers an AI‑assisted, stage‑gated process across discovery, planning, baseline conversion, and continuous validation with human‑in‑the‑loop checkpoints. The workflow integrates with VS Code and GitHub Copilot, supports incremental “flow‑group” migration, and accommodates existing black‑box tests. The article also previews mission‑critical capabilities arriving for Standard and Hybrid (HL7, MLLP, Rules Engine, MSMQ, Oracle DB, flat‑file generation, Integration Accounts, and more), giving teams a repeatable, auditable modernization path with reduced risk. Announcing Microsoft Host Integration Server 2028: Modern connectivity for IBM Mainframes Midranges Host Integration Server 2028 (HIS 2028) is the next HIS release, delivered as a standalone SKU decoupled from BizTalk. It modernizes platform foundations (.NET 10) and, for non‑SNA features, introduces Linux support. New investments include Foundry integration for agent scenarios, REST APIs for DB2 and Transaction Integrator workloads, Entra ID and Azure Arc for hybrid management, a move to Visual Studio Code for designers, and alignment with newer IBM middleware. The post also lists product cleanup and deprecations (e.g., 32‑bit, WMI/WCF, BizTalk adapters), helping enterprises secure, govern, and operate host connectivity for years ahead. Easy Auth Configuration for Logic App Standard through CI/CD Enabling App Service Easy Auth on Logic Apps Standard can break run‑history views because SAS‑based runtime calls are blocked before the Logic Apps engine can validate them. This article explains two remedies: allow unauthenticated requests (so the runtime enforces its own auth), or keep Easy Auth strict and exclude runtime endpoints (e.g., /runtime/*) using authsettingsV2. It provides CI/CD‑ready approaches via ARM/Bicep templates or a post‑deployment REST API call, and highlights key settings such as requireAuthentication, unauthenticatedClientAction, excludedPaths, and allowedApplications. The guidance restores run‑history usability while maintaining enterprise authentication policies. Run Javascript code on Agent Loop Azure Logic Apps Agent Loop now supports a JavaScript code interpreter, extending earlier code‑execution support and enabling reliable computations, validations, and transformations alongside LLMs. The runtime executes generated or pre‑written code inside a V8 isolate using the isolated‑vm library, providing memory limits, timeouts, and failure isolation (not a full sandbox) to reduce blast radius. A worked example shows expense‑validation with agent tools orchestrated in a workflow. For Consumption, attaching an Integration Account provides isolated compute for the interpreter. The capability helps teams combine deterministic steps with agentic reasoning to deliver robust, auditable outcomes. Bulk-configure diagnostic settings on Azure Logic Apps Consumptions LA‑BulkDiag is a single‑file PowerShell script that bulk‑applies diagnostic settings across Logic Apps Consumption in a resource group. It inventories workflows, supports quick scopes (bare/all/pick), verifies destinations, auto‑renames on name collisions, and ships with 129 Pester tests. Presets cover logs, metrics, and workflow‑runtime categories; selection grammar enables non‑interactive runs suitable for CI. The post includes quick‑start commands and clarifies scope: it targets Consumption only (not Standard) and doesn’t configure Event Hub sinks. The result is faster, consistent observability at scale without repetitive portal clicks or accidental overwrites. Clean up idle and always-failing Azure Logic App Consumption LA‑CleanUp is a PowerShell utility that scans a subscription for Logic Apps Consumption workflows, classifying them as Idle (no runs in N days) or AlwaysFailing (runs in the window with zero successes). It can export candidates to CSV, then guide per‑item deletion with y/N/q prompts, reporting final counts. Under the hood, it uses OData filters and $top=1 queries for fast server‑side checks, caches an ARM token once, and intentionally avoids cross‑subscription operations. Scope notes: it doesn’t touch Standard workflows or API connections. The tool reduces noise, costs, and operational drag from abandoned or broken apps. News from our community Spec2Integration Post by Balbir Singh Spec2Integration proposes a spec-driven approach to building Azure Integration Services solutions. The open-source toolkit guides teams from a product brief through specification, modeling, contracts, mapping, and architecture to a deployable implementation targeting Azure Logic Apps, Functions, and related services. It includes governance gates for idempotency, observability, retries, and PII handling, plus a VS Code extension that visualizes pipeline status and the integration representation. Templates and tooling support greenfield projects and BizTalk migrations. The result aims to standardize repeatable steps, reduce failure modes, and accelerate delivery while keeping architectural control outside individual workflows. Stateful Orchestration in Azure: When Logic Apps Break, and What to Do Instead Post by Al Ghoniem, MBA This article examines where stateful orchestration with Azure Logic Apps can fall short and how to design around those gaps. It differentiates execution state from business state and highlights common failure modes: long-running instances, retry-induced duplicates, partial completion across SAP/Oracle/APIs, lost correlation, and unowned DLQs. It then contrasts orchestration choices—stateful Logic Apps, Durable Functions, Service Bus–backed orchestration, and choreography—emphasizing idempotency, correlation, reconciliation, and compensation. The guidance steers architects toward a control and observability layer so production incidents can be traced, replayed, and recovered without relying on workflow run history alone. Logic Apps Announcements at Microsoft Build Video by Sebastian Meyer This video recaps Logic Apps announcements from Microsoft Build with insights from a member of the product team. It highlights newly introduced capabilities and shares resources for deeper dives. Viewers get a concise overview of what’s new, why it matters for integration practitioners, and where to learn more. The discussion points architects toward practical use cases and next steps, making it a useful primer for anyone assessing roadmap impacts on existing or upcoming Azure Integration Services projects. Logic Apps Standard vs. Consumption: Which Plan Should You Choose? Post by Chiranjib Ghatak The article compares Logic Apps Standard and Consumption, explaining differences in hosting models, pricing, networking, and development experience. It outlines when to pick each plan, noting Standard’s single-tenant model, VNet/private endpoints, built-in connectors, and local DevOps workflow, versus Consumption’s pay-per-execution model and simplicity for sporadic or low-volume workloads. It also covers performance trade-offs, stateful vs. stateless options available in Standard, and typical enterprise scenarios where Standard provides predictable costs and better throughput. Azure Connector Namespaces: Managed Connectors Beyond Logic Apps Post by Şahin Özdemir This post introduces Azure Connector Namespaces and previews managed connectors for Azure Functions, extending the Logic Apps connector ecosystem to more compute services. It explains the motivation, how namespaces decouple connectors from workflows, and the benefits: reduced custom code, consistent authentication via managed identity, and reuse of Microsoft-managed integrations. A step-by-step walkthrough shows creating a namespace, adding a managed connector, and using the Azure Connectors .NET SDK in Functions, illustrating how teams can standardize connectivity while keeping business logic in code. Stop working harder and start flowing smarter, with Logic Apps Automation Post by Sonny Gillissen Sonny Gillissen explores Logic Apps Automation, a new, governed experience for building enterprise automations. He explains the Project → Application → Workflow model, dedicated portal (auto.azure.com), and reusable Sandboxes for agent code. The post shows how the AI assistant can scaffold workflows from intent, with Knowledge sources to ground agents, while monitoring and analytics provide visibility. Benefits include familiar Logic Apps design, reduced operational overhead, and scale-to-zero. Current gaps are noted—OBO auth shift, occasional assistant syntax issues, managed vs. built‑in connector choices, no migration tooling yet, and pending VNet/private endpoint support. Stop Using Static Filters! Automate DIXF Exports with Logic App Post by Anitha Eswaran Anitha Eswaran demonstrates how to make DIXF exports in D365FO dynamic using Azure Logic Apps and a small X++ customization. A custom OData action updates the DIXF Definition Group filter at runtime based on a parameter such as Customer Group. A Logic App triggered by a business event parses the input, stores the value, calls the OData action, invokes the standard ExportToPackage API, and then retrieves the download URL via GetExportedPackageUrl to fetch the ZIP with a time‑limited SAS token. Screenshots and code samples illustrate the end‑to‑end flow and implementation details. Logic Apps Agent Loops: Master Class Video by Stephen W Thomas Stephen W Thomas compiles his full Logic Apps Agent Loop series into one master‑class video. It covers getting started with Agent Loop on Logic Apps Standard, a human‑in‑the‑loop pattern used to resolve failed code translations, interactive chat agents with secure website embedding via Easy Auth, and when to choose the Consumption tier for simpler, pay‑as‑you‑go deployments. The chaptered format lets viewers jump to relevant topics. The emphasis is on the orchestration pattern—agents that select and compose tools to achieve goals—offering a practical foundation for teams moving from deterministic workflows toward agentic automation. Forget Sampling — This One host.json Setting Cuts Logic Apps Telemetry Costs by 80% Post by Daniel Jonathan This article tackles high Application Insights ingestion costs in Logic Apps Standard and shows a data‑driven path to reduce spend. Through a controlled experiment, it demonstrates that switching Runtime.ApplicationInsightTelemetryVersion to v2 in host.json delivers ~80% reduction without sacrificing troubleshooting. Further options include disabling dependency tracking (eliminates AppDependencies with the trade‑off of losing per‑call HTTP detail) and using adaptive sampling for marginal additional savings, while excluding exceptions. It also explains why some run‑level telemetry bypasses sampling and how to toggle sampling via an environment variable for short‑term diagnostics. Production Is the Only Truth in Integration Post by Marcelo Gomes This piece reframes integration success through a production‑first lens. It argues that reliability emerges when systems are designed for failure as the norm, not the exception. The article urges separating orchestration from business logic—using tools like Azure Logic Apps for coordination and Azure Functions for rules and transformations—to keep retries safe and evolution predictable. It positions production‑readiness as a design concern, emphasizing idempotency, replay, observability, runbooks, and ownership. The practical outcome is reduced operational risk and cost, more predictable behavior, and greater business trust in automated processes. DevUP Talks #05 – Logic Apps Tips & Tricks with Sandro Pereira Video by Mattias Lögdberg In this session, Sandro Pereira distills practical guidance from real projects to help teams build more resilient Logic Apps. Topics include applying environment‑specific timer conditions, deploying Logic Apps in a disabled state to control activation during releases, and using User‑Managed Identity with Azure Service Bus in Logic Apps Standard. The video focuses on patterns that improve reliability, security, and operational control across environments, offering actionable advice for developers and architects working in Azure Integration Services who want fewer surprises in production and a smoother deployment lifecycle. Logic Apps: Service Bus with User‑Assigned Managed Identity Post by Sandro Pereira This best‑practices guide shows how to configure the Azure Service Bus connector in Logic Apps Standard to use a user‑assigned managed identity. Sandro Pereira explains why system‑assigned identities complicate CI/CD—RBAC can’t be fully declared until the identity exists—then demonstrates a pattern that keeps deployments reproducible. The approach uses app settings for the Service Bus namespace and identity resource ID, a custom serviceProviderConnections entry referencing those settings, and workflow actions bound to that connection. The result is secretless, declarative authentication that avoids RBAC timing issues across environments. Logic App Consumption Bulk Failed Runs Resubmit Tool Post by Sandro Pereira Sandro Pereira introduces a small .NET Windows utility that lists and bulk resubmits failed Logic Apps Consumption runs. After authenticating to Azure, users supply the Logic App name, resource group and subscription. The tool can optionally filter by a date range, otherwise it returns up to 250 failed runs for fast triage. It targets a common pain point the portal features don’t fully streamline and includes a link to the GitHub source so teams can adapt or integrate it into operational workflows. A concise “one‑minute brief” outlines the problem and practical benefits. Control the Initial State of Logic Apps Standard Workflows Post by Sandro Pereira This tip explains how to prevent Logic Apps Standard workflows from starting immediately after deployment—a common production risk. Instead of a state property in ARM/Bicep, the initial state is controlled via App Settings on the underlying App Service. By setting Workflows..FlowState to Disabled (in local.settings.json and/or app settings), teams ensure workflows deploy in a safe, non‑running state. The article outlines the rationale, differences from Consumption, and provides concrete examples and screenshots to adopt the practice across environments.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.Logic Apps Newsletter - May 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month May 2026's Ace Aviator: Yahya Ajwad What's your role and title? What are your responsibilities? I work as Chief Architect and AI Lead at Epical. My role is centered around technical leadership, architecture, and advisory mostly within cloud adoption and transformation programs. I help customers design and implement integration platforms. I also support customers in navigating the AI landscape, with a focus on how integration platforms impact AI readiness and how AI can be used to create value in the platforms we build. Internally at Epical, I lead our Microsoft and Azure cloud integration offering, as well as our CoreAI team and AI initiatives. Can you give us some insights into your day-to-day activities? One moment it is about how we can utilize AI to deliver things cheaper and faster without compromising security, governance and quality. Next, a customer contacts us with an undocumented BizTalk environment asking us what to do next (that's where the fun begins). Usually followed up by the question about how much does their future integration platform in Azure will cost down to the last cent (good luck answering that 😜 hint: the right answer is always: "less than BizTalk"). And hey, public cloud might not be good enough for their security, so thank God for private connectivity. I also spend time helping customers identify the best cloud integration strategies and patterns and for their business needs, choosing the right platforms and components for specific use cases, and ensuring that the platforms we design are as secure, scalable, maintainable, and cost-efficient as possible. Increasingly, this also includes sprinkling AI so bosses are happy (joking I'm a true AI believer myself). Internally, I support Epical with technical business development and help ensure that we stay relevant. What motivates and inspires you to be an active member of the Aviators/Microsoft community? I honestly believe that IT in general would never have been the same without communities and the willingness to share knowledge and support one another. The Logic Apps and Azure Integration community is especially unique because it is both practical and open. People share real experiences which makes it incredibly valuable when trying to solve real-world challenges. What motivates me is the opportunity to learn by sharing, receive feedback, and be part of a community where everyone contributes to each other’s growth. Between us, I'm here for the stickers ;) Looking back, what advice do you wish you had been given earlier? Be kind, stay curious and be helpful. Share what you know, even if it feels small or irrelevant. Those small insights often help others more than you think and that will definitely help you grow. Also, focus on learning the fundamentals. Tools and platforms change quickly, and what is popular today might not matter in a few weeks. Strong basics will always stay relevant. Keep learning and try new things all the time. What has helped you grow professionally? Being around kind, skilled, and generous people both in the community and at work who are willing to teach, challenge my thinking, and share their knowledge. Also, finding mentors who are open to mentor me, listen to all my questions even the silly ones, and who are willing to guide me and correct me when I’m hallucinating. If you had a magic wand that could create a feature in Logic Apps, what would it be? I don’t need to wish for one, you guys (Shout-out to Harold, Dyvia and the team) have already created it: Logic Apps Migration Assistant Agents. That stuff is definitely magic. News from our product group Network Connectivity Check APIs for Logic App Standard This post introduces built-in network troubleshooting APIs for Logic App Standard when integrated with a virtual network. Three endpoints—connectivityCheck, dnsCheck, and tcpPingCheck—let you validate end‑to‑end connectivity to services such as Azure SQL, Key Vault, Storage, Service Bus, and Event Hubs, perform DNS resolution, and test TCP reachability from the actual worker hosting your workflows. It covers supported provider types, credential options including Managed Identity and app settings, example payloads, and known limitations (e.g., SMB port 445 cannot be tested). Step-by-step guidance shows how to call the APIs via Azure API Playground or CLI to quickly isolate network issues. Service Bus SBMP Retirement: What BizTalk Server 2020 Customers Need to Know Azure Service Bus will retire the Service Bus Messaging Protocol (SBMP) on September 30, 2026, impacting BizTalk Server 2020 customers using the SB‑Messaging adapter. Microsoft has released a hotfix that adds Advanced Message Queuing Protocol (AMQP) support to the adapter for CU6 and CU7. With the hotfix, AMQP becomes the default transport while SBMP remains an opt‑in fallback; an updated hotfix based on the new Service Bus SDK is expected in June. Guidance includes migrating configurations to AMQP, installing and validating the hotfix in non‑production, and testing large message/file scenarios. The hotfix can be requested via support (KB5091375). Migrate Data Ingestion from Data Collector to Log Ingestion With the HTTP Data Collector API for Log Analytics deprecated and heading out of support in September 2026, this guide shows Logic Apps users how to move to the Log Ingestion API. It explains impacts—such as 403 errors for new Data Collector connections and missing data in newly created custom log tables—and provides a migration path using the HTTP action. Steps include creating a Data Collection Endpoint (DCE) and Data Collection Rule (DCR), deriving the full ingestion URL, mapping sample data to define schema, assigning the Monitoring Metrics Publisher role to the Logic App’s managed identity, and verifying success (HTTP 204). Introducing AI Skill Assessment in Azure API Center Azure API Center now includes automated AI skill assessment, providing governance and quality scoring for skills at scale using an “LLM‑as‑a‑judge” approach. The system evaluates outputs against defined criteria and ships with four default dimensions—Documentation Clarity, Help Completeness, Discoverability, and Safe Usage—each scored 1–5 with configurable thresholds. Developers get detailed reports showing pass/fail, per‑dimension scores, structural checks, and schema validation, helping them decide which skills are production‑ready. Platform administrators can extend or customize criteria to match organizational standards. The feature centralizes oversight and reduces manual review effort, improving confidence when adopting AI skills across integration solutions. Introducing the plugin marketplace for Azure API Center Azure API Center adds a plugin marketplace endpoint (public preview) that exposes a version‑controlled catalog of organizational AI plugins—such as MCP servers and skills—directly from your API Center data plane. Developers can discover and install plugins from familiar tools like Claude Code and GitHub Copilot CLI using simple marketplace commands. The endpoint inherits the API Center portal’s authentication model, ensuring governance and security while platform teams control publication. The article explains the problem it addresses, the marketplace.git URL format, quick start commands, and documentation to enable the feature—streamlining how teams curate, manage, and consume AI plugins in enterprise environments. News from our community Control the Initial State of Logic Apps Standard Workflows Post by Sandro Pereira This tip explains how to prevent Logic Apps Standard workflows from auto-starting after deployment, a risky default in production. Unlike Consumption, Standard doesn’t expose a state property in ARM. Instead, each workflow’s initial state is controlled via App Service application settings using the pattern “Workflows.<WorkflowName>.FlowState=Disabled.” The post shows how to define these keys in local.settings.json (or pipelines/Bicep), deploy with workflows disabled, and enable them when ready. It also notes acceptable values (Disabled/disabled) and clarifies that omitting the keys leaves workflows enabled by default—reducing unwanted executions and noisy alerts. 10 Azure Function App Limitations for Enterprise Integration Post by Tarun Garg The post outlines ten reasons Azure Function Apps may be a poor fit for enterprise integration workloads. Issues include cold-start latency, limited orchestration and state management, operational complexity at scale, and the need to hand-roll observability. It also highlights security and network isolation challenges, cost variability under heavy throughput, strong dependence on custom code, risks around versioning and breaking changes, and insufficient governance controls for integration use cases. The takeaway: Function Apps excel at granular compute, but integration programs often benefit from managed orchestration layers and patterns better aligned to enterprise requirements. Logic Apps Standard: how accidentally blocking access from Edge results in CORS errors Post by Şahin Özdemir Şahin Özdemir explains a troubleshooting case where Logic Apps Standard action inputs/outputs stopped loading in the Azure portal, appearing like a CORS issue. The root cause was a blocked “Local Network Access” permission in Microsoft Edge, not misconfigured CORS. The article advises checking Edge’s site permissions and re-enabling local network access before diving into CORS diagnostics. By validating browser settings first, engineers can avoid unnecessary changes to integration apps and resolve portal rendering failures quickly—saving time and reducing confusion when workflow views suddenly fail to load. Logic apps – Handling AND OR conditions Post by Anitha Eswaran Anitha Eswaran explains how to correctly implement combined AND/OR logic in Azure Logic Apps when the designer view becomes confusing. Using a real example—validating item numbers—she shows how to check for empty values or specific suffixes (W/WN) and when to terminate processing. The article demonstrates building expressions to explicitly control evaluation order and outcomes, avoiding unintended behavior from default AND logic. Practical screenshots and expression snippets help readers structure conditions, handle arrays from trigger data, and create maintainable workflows that reflect real business rules. Why Enterprises Are Migrating from Logic Apps (Consumption) to Logic Apps (Standard): Practical Insights from the Field Post by Kunal Saha Kunal Saha outlines why organizations reach an inflection point where Logic Apps Standard becomes a better fit than Consumption. Drawing from field experience, he highlights drivers like consolidated app-level management, richer local development workflows, environment isolation, and cost predictability for sustained workloads. The piece discusses when per-execution billing ceases to be efficient, how Standard’s hosting model supports enterprise governance, and migration considerations around triggers, connectors, and stateful patterns. The article encourages teams to evaluate workload characteristics and operational needs to determine the right time to modernize to Standard. Event Debouncing with Logic Apps and Azure Table Storage Post by Daniel Jonathan This article presents an event debouncing pattern for webhook-heavy systems using three Logic Apps and a single Azure Table Storage table. Incoming events are buffered by upserting rows keyed by entity ID, ensuring only the latest state is retained. A timer-driven workflow processes pending rows after a cooldown window, fetches fresh state from the source, and calls downstream APIs, deleting entries on success or resetting on failure. Benefits include implicit deduplication, reduced downstream load, and operational transparency in Storage Explorer. The pattern suits moderate scale without Service Bus, with caveats for strict ordering or very high throughput scenarios. XML to JSON in Logic Apps: Fixing the “Object vs Array” Trap Post by Prashant Singh Prashant Singh explains a common pitfall when converting XML to JSON in Logic Apps: json(xml(...)) yields an array when multiple nodes exist, but a single object when only one node is present—breaking For each loops. He outlines three remedies: debatch directly with xpath() to always return a node set; wrap the target node with array() to normalize object/array differences; or use coalesce() with array() to safely handle missing nodes. With clear examples and expressions, the post helps engineers avoid brittle assumptions and build resilient workflows that handle single, multiple, or absent records cleanly. DevUP Talks 02 - 2026 Q1 Reflections with Ahmed Bayoumy, Sebastian Meyer and Andrew Wilson Video by Mattias Lögdberg This 12‑minute panel discussion surveys how AI and automation are changing day‑to‑day engineering work. Mattias Lögdberg hosts Ahmed Bayoumy, Sebastian Meyer, and Andrew Wilson to share early field perspectives: the shift from experimentation to production, emerging testing responsibilities around AI‑assisted code, and how integration teams are adapting operating models and skills. The conversation favors practical observations over hype, offering a snapshot of what practitioners are seeing at the start of 2026. It’s a compact watch for leaders tracking real impacts rather than theoretical roadmaps. How low can you code? From ‘drag-and-drop’ dreams to try–catch reality Post by Sonny Gillissen Sonny Gillissen argues that early low‑code promised simplicity but often obscured complexity with visual designers and limited tooling. He suggests AI can shift low‑code from diagramming boxes to describing intent—letting teams express business behavior in natural terms, with systems generating implementations. The piece calls for focusing on domain clarity, robust data/APIs, and guardrails over chasing more drag‑and‑drop. For integration engineers, it frames a path where Logic Apps and related platforms become orchestration shells around AI‑assisted specifications, improving maintainability without hiding the hard parts. Legacy Integration to Azure: 40% Cost Savings and Faster Delivery Post by Adaptiv (post by Simon Clendon) This piece outlines lessons from migrating legacy integration platforms to Microsoft Azure. It details the discovery work needed to untangle historical integrations, the diplomacy required with stakeholders, and the engineering patterns that de-risk cutovers. Highlights include modernizing HR workflows, establishing clear migration decision trees, and treating AI as a force multiplier rather than a silver bullet. The article emphasizes measurable outcomes—around 40% cost savings and faster delivery—while cautioning against underestimating analysis, testing, and organizational change, and recommending experienced partners to accelerate the journey. Using the Right Tool Is Not Over‑Engineering Post by Marcelo Gomes Marcelo Gomes argues that many integration failures stem from tool misalignment rather than flawed logic. Using a market‑stall analogy, he outlines when to rely on API Management for exposure and control, where Logic Apps should orchestrate rather than absorb all work, and why Azure Storage underpins durable, production‑ready designs. The piece encourages architects to map responsibilities explicitly—governance at the edge, orchestration in workflows, compute where it belongs—so systems scale cleanly without masking complexity under a single service. Choosing fit‑for‑purpose components, he suggests, is discipline—not over‑engineering. Using Event Grid to detect deleted files and trigger Logic App Post by Sandro Pereira (author: Luis Rigueira) This walkthrough shows how to capture Azure Storage blob deletion events with Event Grid and invoke a Logic App for downstream actions like audit, recovery, or notifications. It explains why native Blob triggers don’t fire on delete, then sets up a System Topic on the storage account, configures a Logic App with the “When a resource event occurs” trigger for Microsoft.Storage.BlobDeleted, and parses the event payload for container, file name, content‑type, and timestamp. The post provides expressions and screenshots to build the flow end‑to‑end, enabling reliable reactions to file deletions without custom functions.
