Microsoft BizTalk Server Product Lifecycle Update
For more than 25 years, Microsoft BizTalk Server has supported mission-critical integration workloads for organizations around the world. From business process automation and B2B messaging to connectivity across industries such as financial services, healthcare, manufacturing, and government, BizTalk Server has played a foundational role in enterprise integration strategies. To help customers plan confidently for the future, Microsoft is sharing an update to the BizTalk Server product lifecycle and long-term support timelines. BizTalk Server 2020 will be the final version of BizTalk Server. Guidance to support long-term planning for mission-critical workloads This announcement does not change existing support commitments. Customers can continue to rely on BizTalk Server for many years ahead, with a clear and predictable runway to plan modernization at a pace that aligns with their business and regulatory needs. Lifecycle Phase End Date What’s Included Mainstream Support April 11, 2028 Security + non-security updates and Customer Service & Support (CSS) support Extended Support April 9, 2030 CSS support, Security updates, and paid support for fixes (*) End of Support April 10, 2030 No further updates or support (*) Paid Extended Support will be available for BizTalk Server 2020 between April 2028 and April 2030 for customers requiring hotfixes for non-security updates. CSS will continue providing their typical support. BizTalk Server 2016 is already out of mainstream support, and we recommend those customers evaluate a direct modernization path to Azure Logic Apps. Continued Commitment to Enterprise Integration Microsoft remains fully committed to supporting mission-critical integration, including hybrid connectivity, future-ready orchestration, and B2B/EDI modernization. Azure Logic Apps, part of Azure Integration Services — which includes API Management, Service Bus, and Event Grid — delivers the comprehensive integration platform for the next decade of enterprise connectivity. Host Integration Server: Continued Support for Mainframe Workloads Host Integration Server (HIS) has long provided essential connectivity for organizations with mainframe and midrange systems. To ensure continued support for those workloads, Host Integration Server 2028 will ship as a standalone product with its own lifecycle, decoupled from BizTalk Server. This provides customers with more flexibility and a longer planning horizon. Recognizing Mainframe modernization customers might be looking to integrate with their mainframes from Azure, Microsoft provides Logic Apps connectors for mainframe and midrange systems, and we are keen on adding more connectors in this space. Let us know about your HIS plans, and if you require specific features for Mainframe and midranges integration from Logic Apps at: https://aka.ms/lamainframe Azure Logic Apps: The Successor to BizTalk Server Azure Logic Apps, part of Azure Integration Services, is the modern integration platform that carries forward what customers value in BizTalk while unlocking new innovation, scale, and intelligence. With 1,400+ out-of-box connectors supporting enterprise, SaaS, legacy, and mainframe systems, organizations can reuse existing BizTalk maps, schemas, rules, and custom code to accelerate modernization while preserving prior investments including B2B/EDI and healthcare transactions. Logic Apps delivers elastic scalability, enterprise-grade security and compliance, and built-in cost efficiency without the overhead of managing infrastructure. Modern DevOps tooling, Visual Studio Code support, and infrastructure-as-code (ARM/Bicep) ensure consistent, governed deployments with end-to-end observability using Azure Monitor and OpenTelemetry. Modernizing Logic Apps also unlocks agentic business processes, enabling AI-driven routing, predictive insights, and context-aware automation without redesigning existing integrations. Logic Apps adapts to business and regulatory needs, running fully managed in Azure, hybrid via Arc-enabled Kubernetes, or evaluated for air-gapped environments. Throughout this lifecycle transition, customers can continue to rely on the BizTalk investments they have made while moving toward a platform ready for the next decade of integration and AI-driven business. Charting Your Modernization Path Microsoft remains fully committed to supporting customers through this transition. We recognize that BizTalk systems support highly customized and mission-critical business operations. Modernization requires time, planning, and precision. We hope to provide: Proven guidance and recommended design patterns A growing ecosystem of tooling supporting artifact reuse Unified Support engagements for deep migration assistance A strong partner ecosystem specializing in BizTalk modernization Potential incentive programs to help facilitate migration for eligible customers (details forthcoming) Customers can take a phased approach — starting with new workloads while incrementally modernizing existing BizTalk deployments. We’re Here to Help Migration resources are available today: Overview: https://aka.ms/btmig Best practices: https://aka.ms/BizTalkServerMigrationResources Video series: https://aka.ms/btmigvideo Feature request survey: https://aka.ms/logicappsneeds Reactor session: Modernizing BizTalk: Accelerate Migration with Logic Apps - YouTube Migration Agent (Complete refactoring from BizTalk to Logic Apps): Bringing all your Integration workloads to Logic Apps Standard | Microsoft Community Hub We encourage customers to engage their Microsoft accounts team early to assess readiness, identify modernization opportunities, and explore assistance programs. Your Modernization Journey Starts Now BizTalk Server has played a foundational role in enterprise integration success for more than two decades. As you plan ahead, Microsoft is here to partner with you every step of the way, ensuring operational continuity today while unlocking innovation tomorrow. To begin your transition, please contact your Microsoft account team or visit our migration hub. Thank you for your continued trust in Microsoft and BizTalk Server. We look forward to partnering closely with you as you plan the future of your integration platforms. Frequently Asked Questions Do I need to migrate now? No. BizTalk Server 2020 is fully supported through April 11, 2028, with paid Extended Support available through April 9, 2030, for non-security hotfixes. CSS will continue providing their typical support. You have a long and predictable runway to plan your transition. Will there be a new BizTalk Server version? No. BizTalk Server 2020 is the final version of the product. What happens after April 9, 2030? BizTalk Server will reach End of Support, and security updates or technical assistance will no longer be provided. Workloads will continue running but without Microsoft servicing. Is paid support available past 2028? Yes. Paid extended support will be available through April 2030 for BizTalk Server 2020 customers looking for non-security hotfixes. CSS will continue to provide the typical support. What is the end of sale date for BizTalk Server? We will announce an end of sale date for BizTalk Server on July 2026. What about BizTalk Server 2016 or earlier versions? Those versions are already out of mainstream support. We strongly encourage moving directly to Logic Apps rather than upgrading to BizTalk Server 2020. Will Host Integration Server continue? Yes. Host Integration Server (HIS) 2028 will be released as a standalone product with its own lifecycle and support commitments. Can I reuse BizTalk Server artifacts in Logic Apps? Yes. Most of BizTalk maps, schemas, rules, assemblies, and custom code can be reused with minimal effort using Microsoft and partner migration tooling. We welcome feature requests here: https://aka.ms/logicappsneeds Does modernization require moving fully to the cloud? No. Logic Apps supports hybrid deployments for scenarios requiring local processing or regulatory compliance, and fully disconnected environments are under evaluation. More information of the Hybrid deployment model here: https://aka.ms/lahybrid. Does modernization unlock AI capabilities? Yes. Logic Apps enables AI-driven automations through Agent Loop, improving routing, decisioning, and operational intelligence. Where do I get planning support? Your Microsoft account team can assist with assessment and planning. Migration resources are also linked in this announcement to help you get started. Microsoft Corporation
Clean up idle and always-failing Azure Logic App Consumption
If you’ve inherited an Azure subscription that’s been collecting Logic Apps Consumption workflows for a couple of years, you already know the shape of the problem: dozens of TestLA, webhook-test-2, poc-for-jira-FINAL workflows in the portal, half of them still Enabled, half of them quietly failing every five minutes against a connection that was rotated last quarter. They’re cheap, but they’re not free — polling triggers keep firing, alert rules keep paging, abandoned Microsoft.Web/connections keep pinning permissions, and the portal’s workflow list keeps getting harder to read. Source + full docs: GitHub - dengyanbo/LA-CleanUp What it gives you Two color-coded tables — Idle (no runs in the last -IdleDays days; never-run workflows land here too) and AlwaysFailing (ran in the window, but not a single Succeeded ). An optional, timestamped CSV ( LogicAppCleanup-Candidates-<yyyyMMdd-HHmmss>.csv ) with a stable column set, easy to drop in a Teams channel or PR for owner review before you delete anything. A per-item y/N/q deletion loop — y deletes, N /Enter skips, q quits the loop without touching anything else. A final summary with scanned / idle / always-failing / deleted / skipped / failed counts. Server-side OData $filter on run history so the scan is fast even on a subscription with thousands of workflow runs in the window. Lazy State lookup (Enabled/Disabled) — only fetched for actual candidates, not for every healthy workflow. What it is not: it does not touch Logic Apps Standard ( Microsoft.Web/sites with kind=workflowapp ) — those store run history in storage tables and need a completely different tool (see LogicAppAdvancedTool). It also does not GC Microsoft.Web/connections , and it does not iterate subscriptions — one invocation, one subscription, deliberately. Quick start Prerequisites PowerShell 5.1+ (Windows PowerShell or PowerShell 7 — both fine). Azure CLI on PATH: https://aka.ms/azcli An interactive az login against the subscription that owns the Logic Apps. Logic App Contributor on the relevant RGs (or plain Contributor) is enough — you need list + delete on Microsoft.Logic/workflows , plus the ARM token your az login already grants. Get the script git clone https://github.com/dengyanbo/LA-CleanUp.git cd LA-CleanUp One-liner — defaults (90-day idle, 90-day failure window, current sub) .\Invoke-LogicAppCleanup.ps1 A typical run looks like this: [INFO] Active subscription: Contoso-Integration (1111-2222-...) [INFO] Signed in as : alice@contoso.com [INFO] Idle cutoff : runs older than 2026-02-20T03:08:00Z (>90 days) [INFO] Failure window : checking runs since 2026-02-20T03:08:00Z (last 90 days) [INFO] Listing Logic App (Consumption) workflows... [ OK ] Found 13 workflow(s). [ 1/13] order-processor (rg-integration) [ 2/13] webhook-test (MyTest) ... [ OK ] Scan complete. Idle: 9, AlwaysFailing: 1, Errors: 0 === Idle Logic Apps (no runs in last 90 days) === Name ResourceGroup Location State LastStatus LastRunTime ---- ------------- -------- ----- ---------- ----------- webhook-test MyTest australiaeast Enabled Never poc-for-jira rg-integration eastus Enabled Succeeded 2025-09-04T... ... === Always-Failing Logic Apps (no successful run in last 90 days) === Name ResourceGroup Location State LastStatus LastRunTime ---- ------------- -------- ----- ---------- ----------- nightly-export rg-integration eastus Enabled Failed 2026-05-20T... Export the 10 candidate(s) to CSV? (y/N): y [ OK ] CSV written: ...\LogicAppCleanup-Candidates-20260521-110800.csv Starting per-item deletion review. Answer y to delete, N (or Enter) to skip, q to quit. (1/10) Delete [Idle] webhook-test in MyTest ? (y/N/q): y [INFO] Deleting webhook-test ... [ OK ] Deleted: webhook-test (2/10) Delete [Idle] poc-for-jira in rg-integration ? (y/N/q): N Skipped. ... === Summary === Scanned : 13 Idle : 9 Always-failing : 1 Scan errors : 0 Deleted : 4 Skipped : 6 Delete failures : 0 That’s the whole workflow. The commands you’ll actually use 1. Scope to one resource group with a tighter idle threshold .\Invoke-LogicAppCleanup.ps1 -IdleDays 60 -ResourceGroup rg-integration 2. Only review always-failing apps (skip the idle pile) .\Invoke-LogicAppCleanup.ps1 -SkipIdle 3. Only review idle apps (skip always-failing) .\Invoke-LogicAppCleanup.ps1 -SkipAlwaysFailing 4. Incident-driven cleanup — tight window, focused RG .\Invoke-LogicAppCleanup.ps1 -IdleDays 30 -FailureWindowDays 7 ` -ResourceGroup rg-integration-prod This answers: “Within prod-integration, which workflows haven’t run in a month, and which have been failing all week?” 5. Dry-run (there is no -WhatIf ) The per-item y/N/q prompt is the safety model. To dry-run, just answer N to every prompt — or q at the first one. The CSV is still written before the deletion loop starts, so you walk away with the report and zero deletions. Parameters — cheat sheet Parameter Default Meaning -IdleDays 90 No runs in this many days ⇒ flagged Idle. Never-run workflows land here too. -FailureWindowDays 90 Ran in this window but no Succeeded ⇒ flagged AlwaysFailing. -ResourceGroup (none) Restrict the scan to a single RG. -SkipIdle switch Skip the Idle bucket entirely. -SkipAlwaysFailing switch Skip the AlwaysFailing bucket entirely. Why Invoke-RestMethod instead of az rest This is the gotcha I want every other Logic Apps scripter to know about, because it eats hours. The Logic Apps Management REST API is queried with OData — $top , $filter , the usual: GET /subscriptions/.../workflows/{wf}/runs ?api-version=2016-06-01 &$top=1 &$filter=startTime ge 2026-02-20T03:08:00Z and status eq 'Succeeded' On Windows PowerShell, az is a .cmd shim. The URL you pass to az rest --uri "..." is re-parsed by cmd.exe , and the & characters separating OData query parameters get interpreted as command separators. Symptoms range from '$filter' is not recognized as an internal or external command to silent wrong-page returns where the filter is just dropped and you get the most recent N runs instead. Quoting heroics — single quotes, double quotes, triple-escaped ^& — don’t fully solve it across PS 5.1 and PS 7. The fix is to skip az rest entirely. The script grabs an ARM token once with az account get-access-token , caches it on a script-scoped variable, refreshes it proactively at the 45-minute mark (ARM tokens last ~60), and calls Invoke-RestMethod directly: $tok = az account get-access-token --resource 'https://management.azure.com/' -o json | ConvertFrom-Json Invoke-RestMethod -Method Get -Uri $url ` -Headers @{ Authorization = "Bearer $($tok.accessToken)" } That bypasses cmd.exe entirely. Bonus: caching the token makes the script noticeably faster on subscriptions with many candidates, since we’re no longer shelling out to az for every REST call. Why $top=1 matters more than you’d think The script never pages run history. For each surviving workflow it asks two existence questions: ?api-version=2016-06-01&$top=1&$filter=startTime ge <cutoff> ?api-version=2016-06-01&$top=1&$filter=startTime ge <cutoff> and status eq 'Succeeded' If the first one returns zero rows ⇒ the workflow is Idle. Otherwise, if the second one returns zero rows ⇒ AlwaysFailing. Both queries are O(1) server-side because startTime is indexed and the response is capped at one row. Even on a chatty workflow with tens of thousands of runs in the window, the answer comes back in tens of milliseconds. This is also why the script can afford to be sequential per workflow — there’s no need for parallelism when each existence check is essentially free. Why “AlwaysFailing” is defined the way it is The bucket is “ran in the window, but not a single Succeeded run in the window” — not “all runs are Failed ”. That distinction matters: Workflows whose runs are Running , Waiting , or Cancelled but never Succeeded get classified as AlwaysFailing. That’s usually what you want — a workflow that has been “Waiting” for 30 days is just as broken as one that’s been failing for 30 days. Long-running workflows that legitimately haven’t completed yet look the same to the classifier. If you operate that kind of workflow, widen -FailureWindowDays so a slow but eventually-Succeeded run shows up in the window. The reported LastStatus column in the table is the status of the most recent run, so you can usually eyeball the difference between “failing” and “still running.” A field-tested rollout If you’re running this on a subscription you don’t fully own, this multi-pass rollout has worked well: Run with -SkipAlwaysFailing first. Idle workflows are the safe pile — if they haven’t done anything in 90+ days, deleting them rarely surprises anyone. Export the CSV. Don’t delete yet — answer q at the first delete prompt. Drop the CSV in a Teams channel or PR. Give owners a few days to object. Re-run and actually delete the ones nobody claimed. Then run with -SkipIdle for the AlwaysFailing bucket. These often have an owner who just hasn’t noticed the breakage — treat the first pass as a bug-bash list, not a delete list. Things to know before you run it Consumption only. Logic Apps Standard is out of scope — different model, different APIs, run history in storage tables. Use LogicAppAdvancedTool for those. No -Force , no -WhatIf . The per-item y/N/q prompt is the entire safety model. That’s deliberate — cleanup tools that take a -Force get used with -Force . One subscription per invocation. The script operates on whatever az account show returns. Use az account set --subscription <id> to switch deliberately. Microsoft.Web/connections are not deleted. API connections are typically shared; the script intentionally leaves them alone. GC them with a separate pass. Run history disappears with the workflow. Once you delete the Logic App, Azure removes its run history too. Export the CSV first if you want any record. Enabled vs. Disabled is reported, not enforced. A Disabled workflow can still be Idle. The script shows the state in the table so you can decide. Where to go next The GitHub repo has the full reference — parameter table, CSV schema, the “how it works” deep dive on lazy State fetch, bearer-token caching, server-side $filter , considerations and limitations, and the recommended rollout: 👉 https://github.com/dengyanbo/LA-CleanUp Issues and PRs welcome. A few directions on the roadmap: an optional disable-instead-of-delete mode for the first pass ( PATCH ...?api-version=2019-05-01 with properties.state = 'Disabled' ), a cross-subscription mode that iterates az account list with a confirmation per sub, and a companion API-connection GC script that uses Resource Graph to join connections against workflow definitions in one query.Run Javascript code on Agent Loop
We have recently introduced support for Code interpreters inside of Azure Logic Apps Agent Loop, extending the support we had for Python. When partnered with a LLM, this allow builders to express their goals or intents via natural language and obtain executable results. These capabilities become powerful in the areas of data analysis, visualizations, validations and transformations. Our first language supported for code interpreter is JavaScript, with other languages following later. Historically, customers have had concerns about an LLM performing data analysis, calculations and transformations due to context window exhaustion which can lead to hallucinations. Code interpreters help in this regard as they can perform this analysis without filling up context windows and providing more reliable results. You can see the code interpreter with JavaScript in action in this video from Kent Weare. After watching the video, you can deep dive in the details. How it works When Agent Loop evaluates code generated by an AI agent (for example, through a code interpreter), we run it inside a V8 isolate using the isolated‑vm library. V8 is the JavaScript engine that powers Node.js and Chrome—it’s what actually executes JavaScript code. An isolate is a lightweight, independent environment within V8, with its own memory and execution context. Running code inside an isolate gives us strong separation from the host runtime. Each execution has its own memory (“heap”) and cannot directly access the host’s memory, file system, or network. This helps ensure that agent-generated code stays contained and doesn’t interfere with the rest of the system. This approach is not intended to be a full security sandbox, and we don’t treat it as safe for fully untrusted code. However, it provides meaningful defense-in-depth: Memory usage is limited per isolate, preventing a single execution from consuming all available resources Execution can be bounded with timeouts, allowing us to terminate long-running or infinite loops Failures are isolated, so crashes in agent-generated code won’t bring down the runtime process In practice, this is about reducing blast radius. By isolating execution and enforcing limits, we make sure that code—regardless of whether it’s generated by a user or an AI agent—cannot disrupt the engine that runs it. Use case: Expense Validations To help illustrate, this capability, let’s take an accounts payable example built in Logic Apps Standard. Zava uses a 3 rd party expense application to capture employee expenses. The 3rd party expense application will export transactions in CSV format. Zava has some very specific business validations that need to execute before the expenses can be processed by the ERP. To solve this problem, we will build an agentic business process in Logic Apps that includes our new JavaScript code interpreter. Our code interpreter will be able to ingest and parse our CSV file and then apply our business validations for us. The outcome is a report that identifies both valid and invalid transactions. Prior to uploading to the ERP (Dataverse), we will route our request to a human in the loop process for their oversight. This allows for additional control as unwinding in an ERP is always a tedious task. Below, is a picture of our solution. Within it we can see both deterministic steps before and after our Agent action. Within our agent action, we have tools that will help our agent address our company objectives. These tools include calling a batch API to upload valid expense records to Dataverse. Another tool that will take care of uploading invalid records to a different table, our human in the loop action to seek approval from our human stakeholder and a tool that will help us obtain business knowledge from SharePoint. You might be asking, ok where does the code interpreter come in? Within our Agent action, we will discover a toggle that allows you to enable it. The code interpreter gets invoked based upon instruction in the model. Here is a subset of the prompt from this workflow that describes how to invoke the code interpreter. For example: ### Step 2 -- Parse and Validate The expense CSV data is available from the Get_file_content action. Use code interpreter to parse ALL rows from the CSV. For each row, normalize: Category: title case - Amount: decimal number - SubmittedDate: ISO 8601 format (e.g. "2026-01-05T00:00:00Z") - ReceiptAttached: convert "Yes"/"No" to true/false Then apply the business rules from Step 1 to classify every record as VALID or INVALID. You won’t see the code interpreter modelled as a tool within our agent action, but we see the execution outcome within our run history. In the following screenshot we can see this illustrated. Within our agent action, we can see that we are on our 4 th turn and we have executed the code interpreter action. In the code window, we can see the code that was generated for our us. This is the result of the LLM working together with the code interpreter to generate and execute this code. Note: In this scenario, we are dynamically generating this code at runtime. This allows for ultimate flexibility if we have different source inputs and we are relying upon the LLM and code interpreter to adapt to these fluid inputs. If we were interested in a more deterministic approach we can also pass pre-written code into this action where it can also execute. This will result in less flexibility, but more deterministic behavior. Running JavaScript code in Logic Apps Consumption Agent Loop Logic Apps Consumption has a slightly different architecture to Logic Apps Standard. In Logic Apps Standard, we offer dedicated compute and storage for customers which provides workload isolation across customers. When it comes to Logic Apps Consumption, we provide a multi-tenant offering allowing customers to take advantage of a lower price point due to shared resource utilization. In order to allow customer isolation, customers need to have an integration account attached to their consumption workflow. This will allow the code interpreter to run in isolated compute thus avoiding any potential disruptions to other customers. You can provision an Integration Account by searching for Integration Accounts at the top of the Azure portal. You can select any of the SKUs available, including the Free SKU for non-production/non-SLA scenarios. With an Integration Account created, we can associate this Integration Account with our consumption logic app by clicking on Settings – Integration Account.Bulk-configure diagnostic settings on Azure Logic Apps Consumptions
Bulk-configure diagnostic settings on Azure Logic Apps — without clicking through the Portal LA-BulkDiag is a small, single-file PowerShell script that does the whole job in one guided run. It enumerates every Consumption Logic App in a resource group, shows you which ones already have settings, lets you pick a scope (every bare LA / every LA / a hand-picked subset), and creates the diagnostic setting on each. It auto-renames on collision so re-running is safe, and it ships with 129 Pester tests covering helpers, parameter binding, and end-to-end flows with a mocked az . Source + full docs: GitHub - dengyanbo/LA-BulkDiag: Bulk diagnostics configuration for Azure Logic Apps What it gives you A numbered, color-coded table of every Consumption LA in the RG and its current diagnostic-setting state (bare / has N / list failed). A single scope prompt — bare / all / pick / cancel — so the common cases are one keystroke. Selection grammar for the picker / -Selection : 1,3-5,8 , bare , all , none . Auto-rename on name collision ( la-diag → la-diag-1 → …) so the upsert behavior of Azure’s API never silently replaces an existing setting. Preflight verification of the destination workspace / storage account via az resource show before touching any Logic App. -WhatIf for a dry-run preview. Non-zero exit code if any LA failed, so it composes cleanly in CI. What it is not: it does not target Standard Logic Apps ( Microsoft.Web/sites with kind=workflowapp ) — those use a different API. It also doesn’t target Event Hub destinations. For everything else, see the “Scope and what this is NOT” section in the GitHub README. Quick start Prerequisites PowerShell 5.1+ (Windows PowerShell or PowerShell 7 — both fine). Azure CLI on PATH: https://aka.ms/installazurecliwindows An interactive az login against the subscription that owns the Logic Apps. Built-in Monitoring Contributor on the RG is enough. Get the script git clone https://github.com/dengyanbo/LA-BulkDiag.git cd LA-BulkDiag One-liner — fully interactive You don’t need to know the destination IDs up front; the script will ask: .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -SettingName la-diag You’ll see something like: Sub: my-sub (00000000-...) User: alice@contoso.com Destination not provided on the command line. Configure interactively: (paste the full ARM resource ID; leave blank to skip a destination) Log Analytics workspace resource ID: /subscriptions/.../workspaces/my-ws Storage account resource ID: Inspecting 3 Logic App(s) ... Logic Apps in 'my-rg': [ 1] order-processor bare (no settings) [ 2] notification-sender has 1: corp-governance [ 3] data-loader bare (no settings) How do you want to apply 'la-diag'? 1) bare -- apply to every BARE LA (recommended) 2) all -- apply to EVERY LA (may fail Azure-side on non-bare ones) 3) pick -- go into the selective picker 0) cancel Choice [1]: 1 Applying to every BARE LA. ==> order-processor Creating ... OK (Created). ==> data-loader Creating ... OK (Created). ================ Summary ================ LogicApp FinalName Status -------- --------- ------ order-processor la-diag Created data-loader la-diag Created Selected: 2 Succeeded: 2 Renamed: 0 Failed: 0 Not selected: 1 That’s the whole workflow. The commands you’ll actually use Grab the destination IDs once: $wsId = az monitor log-analytics workspace show -g ws-rg -n my-ws --query id -o tsv $saId = az storage account show -g sa-rg -n mysa --query id -o tsv 1. Apply to every bare LA — fully automated .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -SettingName la-diag -Selection bare -Selection bare skips both the scope prompt and the y/N confirm — perfect for CI. 2. Send to both a workspace and a storage account .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -StorageAccountId $saId ` -SettingName la-diag -Selection all 3. Metrics only, storage-only .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -StorageAccountId $saId -SettingName la-metrics ` -Preset metrics-only -Selection all Available presets: all (default) / logs-only / metrics-only / workflowruntime . 4. Specific Logic Apps by index — non-interactive After running once and seeing the numbered table, you can target them directly: .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection '1,3-5,8' 5. Dry-run before committing .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection all -WhatIf 6. Just inspect — list LAs + existing settings, change nothing .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName whatever -Selection none 7. Run the tests .\unit_test\Run-Tests.ps1 Auto-installs Pester 5 to CurrentUser if missing. Expected: Passed=129 Failed=0 . Selection grammar — cheat sheet Input Meaning 1 , 3 , 7 single index (1-based, matches the table) 1,3,5 multiple indices 1-5 inclusive range 1,3-5,8 mixed bare all LAs with no existing settings (recommended) all every LA (may fail on already-configured ones) none (or empty / q / cancel ) exit without changes Why the auto-rename matters Azure’s diagnostic-settings API is PUT — calling create --name la-diag on a Logic App that already has a setting named la-diag silently replaces the existing one. That’s a footgun if a colleague already set something up by hand. LA-BulkDiag refuses to overwrite. Instead, when -SettingName is already in use on a given LA, it auto-appends -1 , -2 , … until it finds a free name, and reports the actual name in the summary’s FinalName column. If you genuinely want to replace an existing setting, delete it first: az monitor diagnostic-settings delete -n <existing-name> --resource <la-id> Where to go next The GitHub repo has the full reference — parameter table, exit codes, status-value glossary, troubleshooting matrix (RBAC, MFA, throttling, category/sink conflicts), known limitations, and the full test inventory: 👉 https://github.com/dengyanbo/LA-BulkDiag
Announcing the public preview of Oracle Database built-in connector for Azure Logic Apps Standard
Announcing the public preview of Oracle Database built-in connector for Azure Logic Apps Standard Run Oracle Database operations natively in your Logic Apps Standard workflows. Today we’re excited to announce the public preview of Oracle Database built-in connector for Azure Logic Apps (Standard). This connector brings first-class Oracle Database connectivity to single-tenant workflows by running in-process with the Logic Apps runtime, helping you build reliable, high-throughput integrations with Oracle-backed systems while keeping network traffic within your chosen network boundary. Why this matters? In-process execution: Operations execute within the Logic Apps Standard runtime for streamlined connectivity and lower latency. No on-premises data gateway (when your Logic App has network connectivity to Oracle): Simplify architecture and reduce operational overhead. Better fit for enterprise network topologies: Use VNET integration, private endpoints, and network controls consistent with your environment. Purpose-built Oracle capabilities: Get Oracle-focused actions including Execute stored procedure, a common gap for generic JDBC-based approaches. Designed for scale: Built-in connectors align with the direction of Logic Apps Standard for performance and operational consistency across workloads. On-premises integrations: With Hybrid Logic Apps, you can connect on-premises Oracle databases from on-premises-hosted Logic Apps. What can you do with the connector? The Oracle Database built-in connector currently supports the following actions: Get tables: Discover tables (and views, depending on permissions) available to your connection. Get rows: Read rows from a selected table with pagination support. Insert row: Insert a row into a selected table. Execute query: Run SQL statements (for example, select, update, delete) and return results when applicable. Execute stored procedure: Call stored procedures to encapsulate business logic and advanced operations. Connector details at a glance Logic Apps SKU: Standard (single-tenant). Execution model: Built-in (in-process) connector. Connectivity: No gateway required when your Logic App runtime can reach the Oracle endpoint (for example, via VNET integration). Oracle versions: Supports Oracle Database 11 and later (compatible with the managed driver). Authentication: Username and password. Triggers: The connector is actions-only in the current release. Getting started Ensure network connectivity from your Logic App Standard runtime to your Oracle Database endpoint (host and port), including any required DNS and firewall rules. Create a new Oracle Database connection in the Logic Apps designer. Provide connection parameters o Server address o Username o Password Choose a server address format that matches your environment: o Easy Connect (host/port/service name) for quick setup. o TNS descriptor for advanced connection configuration. Add an action (for example, Get rows or Execute stored procedure) and start building your workflow. Known limitations (current release) No triggers: The connector currently supports actions only. Update/Delete actions: Use Execute query or Execute stored procedure for update/delete scenarios. Connection validation: Some connection issues may surface at workflow runtime rather than during connection creation. Timeouts: Default query timeout is 30 seconds (configurable via app settings). The function host may impose an upper limit (commonly up to 10 minutes depending on configuration). Case sensitivity: Oracle identifiers can be case sensitive; ensure table/column names match your schema as defined. Troubleshooting and observability When issues occur, you’ll typically see failures surfaced through workflow run history and diagnostics. Oracle error details are returned as standard connector failures, and many common Oracle error conditions map to familiar HTTP status codes (for example, authentication failures, connectivity issues, and timeouts). 401 (authentication): Verify username/password, account lock status, and password expiry policies. 502 (connectivity): Verify host/port reachability, DNS resolution, firewall rules, and Oracle listener availability. 504 (timeout): Verify query complexity, indexes, and configured timeouts (query timeout and host timeout). 404 (object not found): Verify schema/table/view names and permissions; ensure correct casing. 429 (resource/session limits): Review Oracle session limits and workflow concurrency patterns. Get started today If you’re building new integrations with Oracle, or modernizing legacy workloads, try the Oracle Database built-in connector in your Logic Apps Standard workflows and let us know what you build. We’re especially interested in feedback on triggers, advanced authentication options, and additional Oracle operations you’d like to see next. Thank you for your continued feedback and partnership as we expand built-in connectivity across Azure Logic Apps. References: Connect to Oracle Database from Workflows - Azure Logic Apps | Microsoft LearnLogic 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.Announcing General Availability: Azure Logic Apps Standard Custom Code with .NET 8
We’re excited to announce the General Availability (GA) of Custom Code support in Azure Logic Apps Standard with .NET 8. This release marks a significant step forward in enabling developers to build more powerful, flexible, and maintainable integration workflows using familiar .NET tools and practices. With this capability, developers can now embed custom .NET 8 code directly within their Logic Apps Standard workflows. This unlocks advanced logic scenarios, promotes code reuse, and allows seamless integration with existing .NET libraries and services—making it easier than ever to build enterprise-grade solutions on Azure. What’s New in GA This GA release introduces several key enhancements that improve the development experience and expand the capabilities of custom code in Logic Apps: Bring Your Own Packages Developers can now include and manage their own NuGet packages within custom code projects without having to resolve conflicts with the dependencies used by the language worker host. The update includes the ability to load the assembly dependencies of the custom code project into a separate Assembly context allowing you to bring any NET8 compatible dependent assembly versions that your project need. There are only three exceptions to this rule: Microsoft.Extensions.Logging.Abstractions Microsoft.Extensions.DependencyInjection.Abstractions Microsoft.Azure.Functions.Extensions.Workflows.Abstractions Dependency Injection Native Support Custom code now supports native Dependency Injection (DI), enabling better separation of concerns and more testable, maintainable code. This aligns with modern .NET development patterns and simplifies service management within your custom logic. To enable Dependency Injection, developers will need to provide a StartupConfiguration class, defining the list of dependencies: using Microsoft.Azure.Functions.Extensions.Workflows; using Microsoft.Extensions.DependencyInjection; public class StartupConfiguration : IConfigureStartup { /// <summary> /// Configures services for the Azure Functions application. /// </summary> /// <param name="services">The service collection to configure.</param> public void Configure(IServiceCollection services) { // Register the routing service with dependency injection services.AddSingleton<IRoutingService, OrderRoutingService>(); services.AddSingleton<IDiscountService, DiscountService>(); } } You will also need to initialize those register those services during your custom code class constructor: public class MySampleFunction { private readonly ILogger<MySampleFunction> logger; private readonly IRoutingService routingService; private readonly IDiscountService discountService; public MySampleFunction(ILoggerFactory loggerFactory, IRoutingService routingService, IDiscountService discountService) { this.logger = loggerFactory.CreateLogger<MySampleFunction>(); this.routingService = routingService; this.discountService = discountService; } // your function logic here } Improved Authoring Experience The development experience has been significantly enhanced with improved tooling and templates. Whether you're using Visual Studio or Visual Studio Code, you’ll benefit from streamlined scaffolding, local debugging, and deployment workflows that make building and managing custom code faster and more intuitive. The following user experience improvements were added: Local functions metadata are kept between VS Code sessions, so you don't receive validation errors when editing workflows that depend on the local functions. Projects are also built when designer starts, so you don't have to manually update references. New context menu gestures, allowing you to create new local functions or build your functions project directly from the explorer area Unified debugging experience, making it easer for you to debug. We have now a single task for debugging custom code and logic apps, which makes starting a new debug session as easy as pressing F5. Learn More To get started with custom code in Azure Logic Apps Standard, visit the official Microsoft Learn documentation: Create and run custom code in Azure Logic Apps Standard You can also find example code for Dependency injection wsilveiranz/CustomCode-Dependency-InjectionLogic Apps Aviators Newsletter - April 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month April 2026's Ace Aviator: Marcelo Gomes What’s your role and title? What are your responsibilities? I’m an Integration Team Leader (Azure Integrations) at COFCO International, working within the Enterprise Integration Platform. My core responsibility is to design, architect, and operate integration solutions that connect multiple enterprise systems in a scalable, secure, and resilient way. I sit at the intersection of business, architecture, and engineering, ensuring that business requirements are correctly translated into technical workflows and integration patterns. From a practical standpoint, my responsibilities include: - Defining integration architecture standards and patterns across the organization - Designing end‑to‑end integration solutions using Azure Integration Services - Owning and evolving the API landscape (via Azure API Management) - Leading, mentoring, and supporting the integration team - Driving PoCs, experiments, and technical explorations to validate new approaches - Acting as a bridge between systems, teams, and business domains, ensuring alignment and clarity In short, my role is to make sure integrations are not just working — but are well‑designed, maintainable, and aligned with business goals. Can you give us some insights into your day‑to‑day activities and what a typical day looks like? My day‑to‑day work is a balance between technical leadership, architecture, and execution. A typical day usually involves: - Working closely with Business Analysts and Product Owners to understand integration requirements, constraints, and expected outcomes - Translating those requirements into integration flows, APIs, and orchestration logic - Defining or validating the architecture of integrations, including patterns, error handling, resiliency, and observability - Guiding developers during implementation, reviewing approaches, and helping them make architectural or design decisions - Managing and governing APIs through Azure API Management, ensuring consistency, security, and reusability - Unblocking team members by resolving technical issues, dependencies, or architectural doubts - Performing estimations, supporting planning, and aligning delivery expectations I’m also hands‑on. I actively build integrations myself — not just to help deliver, but to stay close to the platform, understand real challenges, and continuously improve our standards and practices. I strongly believe technical leadership requires staying connected to the actual implementation. What motivates and inspires you to be an active member of the Aviators / Microsoft community? What motivates me is knowledge sharing. A big part of what I know today comes from content shared by others — blog posts, samples, talks, community discussions, and real‑world experiences. Most of my learning followed a simple loop: someone shared → I tried it → I broke it → I fixed it → I learned. For me, learning only really completes its cycle when we share back. Explaining what worked (and what didn’t) helps others avoid the same mistakes and accelerates collective growth. Communities like Aviators and the Microsoft ecosystem create a space where learning is practical, honest, and experience‑driven — and that’s exactly the type of environment I want to contribute to. Looking back, what advice would you give to people getting into STEM or technology? My main advice is: start by doing. Don’t wait until you feel ready or confident — you won’t. When you start doing, you will fail. And that failure is not a problem; it’s part of the learning process. Each failure builds experience, confidence, and technical maturity. Another important point: ask questions. There is no such thing as a stupid question. Asking questions opens perspectives, challenges assumptions, and often triggers better solutions. Sometimes, a simple question from a fresh point of view can completely change how a problem is solved. Progress in technology comes from curiosity, iteration, and collaboration — not perfection. What has helped you grow professionally? Curiosity has been the biggest driver of my professional growth. I like to understand how things work under the hood, not just how to use them. When I’m curious about something, I try it myself, test different approaches, and build my own experience around it. That hands‑on curiosity helps me: - Develop stronger technical intuition - Understand trade‑offs instead of just following patterns blindly - Make better architectural decisions - Communicate more clearly with both technical and non‑technical stakeholders Having personal experience with successes and failures gives me clarity about what I’m really looking for in a solution — and that has been key to my growth. If you had a magic wand to create a new feature in Logic Apps, what would it be and why? I’d add real‑time debugging with execution control. Specifically, the ability to: - Pause a running Logic App execution - Inspect intermediate states, variables, and payloads in real time - Step through actions one by one, similar to a traditional debugger This would dramatically improve troubleshooting, learning, and optimization, especially in complex orchestrations. Today, we rely heavily on post‑execution inspection, which works — but real‑time visibility would be a huge leap forward in productivity and understanding. For integration engineers, that kind of feature would be a true game‑changer. News from our product group How to revoke connection OAuth programmatically in Logic Apps The post shows how to revoke an API connection’s OAuth tokens programmatically in Logic Apps, without using the portal. It covers two approaches: invoking the Revoke Connection Keys REST API directly from a Logic App using the 'Invoke an HTTP request' action, and using an Azure AD app registration to acquire a bearer token that authorizes the revoke call from Logic Apps or tools like Postman. Step-by-step guidance includes building the request URL, obtaining tokens with client credentials, parsing the token response, and setting the Authorization header. It also documents required permissions and a least-privilege custom RBAC role. Introducing Skills in Azure API Center This article introduces Skills in Azure API Center—registered, reusable capabilities that AI agents can discover and use alongside APIs, models, agents, and MCP servers. A skill describes what it does, its source repository, ownership, and which tools it is allowed to access, providing explicit governance. Teams can register skills manually in the Azure portal or automatically sync them from a Git repository, supporting GitOps workflows at scale. The portal offers discovery, filtering, and lifecycle visibility. Benefits include a single inventory for AI assets, better reuse, and controlled access via Allowed tools. Skills are available in preview with documentation links. Reliable blob processing using Azure Logic Apps: Recommended architecture The post explains limitations of the in‑app Azure Blob trigger in Logic Apps, which relies on polling and best‑effort storage logs that can miss events under load. For mission‑critical scenarios, it recommends a queue‑based pattern: have the source system emit a message to Azure Storage Queues after each blob upload, then trigger the Logic App from the queue and fetch the blob by metadata. Benefits include guaranteed triggering, decoupling, retries, and observability. As an alternative, it outlines using Event Grid with single‑tenant Logic App endpoints, plus caveats for private endpoints and subscription validation requirements. Implementing / Migrating the BizTalk Server Aggregator Pattern to Azure Logic Apps Standard This article shows how to implement or migrate the classic BizTalk Server Aggregator pattern to Azure Logic Apps Standard using a production-ready template available in the Azure portal. It maps BizTalk orchestration concepts (correlation sets, pipelines, MessageBox) to cloud-native equivalents: a stateful workflow, Azure Service Bus as the messaging backbone, CorrelationId-based grouping, and FlatFileDecoding for reusing existing BizTalk XSD schemas with zero refactoring. Step-by-step guidance covers triggering with the Service Bus connector, grouping messages by CorrelationId, decoding flat files, composing aggregated results, and delivering them via HTTP. A side‑by‑side comparison highlights architectural differences and migration considerations, aligned with BizTalk Server end‑of‑life timelines. News from our community Resilience for Azure IPaaS services Post by Stéphane Eyskens Stéphane Eyskens examines resilience patterns for Azure iPaaS workloads and how to design multi‑region architectures spanning stateless and stateful services. The article maps strategies across Service Bus, Event Hubs, Event Grid, Durable Functions, Logic Apps, and API Management, highlighting failover models, idempotency, partitioning, and retry considerations. It discusses trade‑offs between active‑active and active‑passive, the role of a governed API front door, and the importance of consistent telemetry for recovery and diagnostics. The piece offers pragmatic guidance for integration teams building high‑availability, fault‑tolerant solutions on Azure. From APIs to Agents: Rethinking Integration in the Agentic Era Post by Al Ghoniem, MBA This article frames AI agents as a new layer in enterprise integration rather than a replacement for existing platforms. It contrasts deterministic orchestration with agent‑mediated behavior, then proposes an Azure‑aligned architecture: Azure AI Agent Service as runtime, API Management as the governed tool gateway, Service Bus/Event Grid for events, Logic Apps for deterministic workflows, API Center as registry, and Entra for identity and control. It also outlines patterns—tool‑mediated access, hybrid orchestration, event+agent systems, and policy‑enforced interaction—plus anti‑patterns to avoid. DevUP Talks 01 - 2026 Q1 trends with Kent Weare Video by Mattias Lögdberg Mattias Lögdberg hosts Kent Weare for a concise discussion on early‑2026 trends affecting integration and cloud development. The conversation explores how AI is reshaping solution design, where new opportunities are emerging, and how teams can adapt practices for reliability, scalability, and speed. It emphasizes practical implications for developers and architects working with Azure services and modern integration stacks. The episode serves as a quick way to track directional changes and focus on skills that matter as agentic automation and platform capabilities evolve. Azure Logic Apps as MCP Servers: A Step-by-Step Guide Post by Stephen W Thomas Stephen W Thomas shows how to expose Azure Logic Apps (Standard) as MCP servers so AI agents can safely reuse existing enterprise workflows. The guide explains why this matters—reusing logic, tapping 1,400+ connectors, and applying key-based auth—and walks through creating an HTTP workflow, defining JSON schemas, connecting to SQL Server, and generating API keys from the MCP Servers blade. It closes with testing in VS Code, demonstrating how agents invoke Logic Apps tools to query live data with governance intact, without rewriting integration code. BizTalk to Azure Migration Roadmap: Integration Journey Post by Sandro Pereira This roadmap-style article distills lessons from BizTalk-to-Azure migrations into a structured journey. It outlines motivations for moving, capability mapping from BizTalk to Azure Integration Services, and phased strategies that reduce risk while modernizing. Readers get guidance on assessing dependencies, choosing target Azure services, designing hybrid or cloud‑native architectures, and sequencing workloads. The post emphasises that migration is not a lift‑and‑shift but a program of work aligned to business priorities, platform governance, and operational readiness. BizTalk Adapters to Azure Logic Apps Connectors Post by Michael Stephenson Michael Stephenson discusses how organizations migrating from BizTalk must rethink integration patterns when moving to Azure Logic Apps connectors. The post considers what maps well, where gaps and edge cases appear, and how real-world implementations often require re‑architecting around AIS capabilities rather than a one‑to‑one adapter swap. It highlights community perspectives and practical considerations for planning, governance, and operationalizing new designs beyond pure connector parity. Pro-Code Enterprise AI-Agents using MCP for Low-Code Integration Video by Sebastian Meyer This short video demonstrates bridging pro‑code and low‑code by using the Model Context Protocol (MCP) to let autonomous AI agents interact with enterprise systems via Logic Apps. It walks through the high‑level setup—agent, MCP server, and Logic Apps workflows—and shows how to connect to platforms like ServiceNow and SAP. The focus is on practical tool choice and architecture so teams can extend existing integration assets to agent‑driven use cases without rebuilding from scratch. Friday Fact: The Hidden Retry Behavior That Makes Logic Apps Feel Stuck Post by João Ferreira This Friday Fact explains why a Logic App can appear “stuck” when calling unstable APIs: hidden retry policies, exponential backoff, and looped actions can accumulate retries and slow runs dramatically. It lists default behaviors many miss, common causes like throttling, and mitigation steps such as setting explicit retry policies, using Configure run after for failure paths, and introducing circuit breakers for flaky backends. The takeaway: the workflow may not be broken—just retrying too aggressively—so design explicit limits and recovery paths. Your Logic App Is NOT Your Business Process (Here’s Why) Video by Al Ghoniem, MBA This short explainer argues that mapping Logic Apps directly to a business process produces brittle workflows. Real systems require retries, enrichment, and exception paths, so the design quickly diverges from a clean process diagram. The video proposes separating technical orchestration from business visibility using Business Process Tracking. That split yields clearer stakeholder views and more maintainable solutions, while keeping deterministic execution inside Logic Apps. It’s a practical reminder to design for operational reality rather than mirroring a whiteboard flow. BizTalk Server Migration to Azure Integration Services Architecture Guidance Post by Sandro Pereira A brief overview of Microsoft’s architecture guidance for migrating BizTalk Server to Azure Integration Services. The post explains the intent of the guidance, links to sections on reasons to migrate, AIS capabilities, BizTalk vs. AIS comparisons, and service selection. It highlights planning topics such as migration approaches, best practices, and a roadmap, helping teams frame decisions for hybrid or cloud‑native architectures as they modernize BizTalk workloads. Logic Apps & Power Automate Action Name to Code Translator Post by Sandro Pereira This post introduces a lightweight utility that converts Logic Apps and Power Automate action names into their code identifiers—useful when writing expressions or searching in Code View. It explains the difference between designer-friendly labels and underlying names (spaces become underscores and certain symbols are disallowed), why this causes friction, and how the tool streamlines the translation. It includes screenshots, usage notes, and the download link to the open-source project, making it a practical time-saver for developers moving between designer and code-based workflows. Logic Apps Consumption CI/CD from Zero to Hero Whitepaper Post by Sandro Pereira This whitepaper provides an end‑to‑end path to automate CI/CD for Logic Apps Consumption using Azure DevOps. It covers solution structure, parameterization, and environment promotion, then shows how to build reliable pipelines for packaging, deploying, and validating Logic Apps. The guidance targets teams standardizing delivery with repeatable patterns and governance. With templates and practical advice, it helps reduce manual steps, improve quality, and accelerate releases for Logic Apps workloads. Logic App Best practices, Tips and Tricks: #2 Actions Naming Convention Post by Sandro Pereira This best‑practices post focuses on action naming in Logic Apps. It explains why consistent, descriptive names improve readability, collaboration, and long‑term maintainability, then outlines rules and constraints on allowed characters. It shows common pitfalls—default names, uneditable trigger/branch labels—and practical tips for renaming while avoiding broken references. The guidance helps teams treat names as living documentation so workflows remain understandable without drilling into each action’s configuration. How to Expose and Protect Logic App Using Azure API Management (Whitepaper) Post by Sandro Pereira This whitepaper explains how to front Logic Apps with Azure API Management for governance and security. It covers publishing Logic Apps as APIs, restricting access, enforcing IP filtering, preventing direct calls to Logic Apps, and documenting operations. It also discusses combining multiple Logic Apps under a single API, naming conventions, and how to remove exposed operations safely. The paper provides step‑by‑step guidance and a download link to help teams standardize exposure and protection patterns. Logic apps – Check the empty result in SQL connector Post by Anitha Eswaran This post shows a practical pattern for handling empty SQL results in Logic Apps. Using the SQL connector’s output, it adds a Parse JSON step to normalize the result and then evaluates length() to short‑circuit execution when no rows are returned. Screenshots illustrate building the schema, wiring the content, and introducing a conditional branch that terminates the run when the array is empty. The approach avoids unnecessary downstream actions and reduces failures, providing a reusable, lightweight guard for query‑driven workflows. Azure Logic Apps Is Basically Power Automate on Steroids (And You Shouldn’t Be Afraid of It) Post by Kim Brian Kim Brian explains why Logic Apps feels familiar to Power Automate builders while removing ceilings that appear at scale. The article contrasts common limits in cloud flows with Standard/Consumption capabilities, highlights the designer vs. code‑view model, and calls out built‑in Azure management features such as versioning, monitoring, and CI/CD. It positions Logic Apps as the “bigger sibling” for enterprise‑grade integrations and data throughput, offering more control without abandoning the visual authoring experience. Logic Apps CSV Alphabetic Sorting Explained Post by Sandro Pereira Sandro Pereira describes why CSV headers and columns can appear in alphabetical order after deploying Logic Apps via ARM templates. He explains how JSON serialization and array ordering influence CSV generation, what triggers the sorting behavior, and practical workarounds to preserve intended column order. The article helps teams avoid subtle defects in data exports by aligning workflow design and deployment practices with how Logic Apps materializes CSV content at runtime. Azure Logic Apps Translation vs Transformation – Actions, Examples, and Schema Mapping Explained Post by Maheshkumar Tiwari Maheshkumar Tiwari clarifies the difference between translation (format change) and transformation (business logic) in Logic Apps, then maps each to concrete Azure capabilities. Using a purchase‑order scenario, he shows how to decode/encode flat files and EDI, convert XML↔JSON, and apply Liquid/XSLT, Select, Compose, and Filter Array for schema mapping and enrichment. A quick reference table ties common tasks to the right action, helping architects separate concerns so format changes don’t break business rules and workflow design remains maintainable.How to revoke connection OAuth programmatically in Logic Apps
There are multiple ways to revoke the OAuth of an API Connection other than clicking on the Revoke button in the portal: For using the "Invoke an HTTP request": Get the connection name: Create a Logic App (Consumption), use a trigger of your liking, then add the “Invoke an HTTP request” Action. Create a connection on the same Tenant that has the connection, then add the below URL to the action, and test it: https://management.azure.com/subscriptions/[SUBSCRIPTION_ID]/resourceGroups/[RESOURCE_GROUP]/providers/Microsoft.Web/connections/[NAME_OF_CONNECTION]/revokeConnectionKeys?api-version=2018-07-01-preview Your test should be successful. For using an App Registration to fetch the Token (which is how you can do this with Postman or similar as well): App Registration should include this permission: For your Logic App, or Postman, get the Bearer Token by calling this URL: https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/token With this in the Body: Client_Id=[CLIENT_ID_OF_THE_APP_REG]&Client_Secret=[CLIENT_SECRET_FROM_APP_REG]&grant_type=client_credentials&scope=https://management.azure.com/.default For the Header use: Content-Type = application/x-www-form-urlencoded If you’ll use a Logic App for this; Add a Parse JSON action, use the Body of the Get Bearer Token HTTP Action as an input to the Parse JSON Action, then use the below as the Schema: { "properties": { "access_token": { "type": "string" }, "expires_in": { "type": "integer" }, "ext_expires_in": { "type": "integer" }, "token_type": { "type": "string" } }, "type": "object" } Finally, add another HTTP Action (or call this in Postman or similar) to call the Revoke API. In the Header add “Authorization”key with a value of “Bearer” followed by a space then add the bearer token from the output of the Parse JSON Action. https://management.azure.com/subscriptions/[SUBSCRIPTION_ID]/resourceGroups/[RESOURCE_GROUP]/providers/Microsoft.Web/connections/[NAME_OF_CONNECTION]/revokeConnectionKeys?api-version=2018-07-01-preview If you want to use CURL: Request the Token Use the OAuth 2.0 client credentials flow to get the token: curl -X POST \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=[CLIENT_ID_OF_APP_REG]" \ -d "scope= https://management.azure.com/.default" \ -d "client_secret=[CLIENT_SECRET_FROM_APP_REG]" \ -d "grant_type=client_credentials" \ https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/token The access_token in the response is your Bearer token. Call the Revoke API curl -X POST "https://management.azure.com/subscriptions/[SUBSCRIPTION_ID]/resourceGroups/[RESOURCE_GROUP]/providers/Microsoft.Web/connections/[NAME_OF_CONNECTION]/revokeConnectionKeys?api-version=2018-07-01-preview" \ -H "Authorization: Bearer <ACCESS_TOKEN>" \ -H "Content-Type: application/json" \ -d '{"key":"value"}' If you face the below error, you will need to grant Contributor Role to the App Registration on the Resource Group that contains the API Connection. (If you want “Least privilege” skip to below ) { "error": { "code": "AuthorizationFailed", "message": "The client '[App_reg_client_id]' with object id '[App_reg_object_id]' does not have authorization to perform action 'Microsoft.Web/connections/revokeConnectionKeys/action' over scope '/subscriptions/[subscription_id]/resourceGroups/[resource_group_id]/providers/Microsoft.Web/connections/[connection_name]' or the scope is invalid. If access was recently granted, please refresh your credentials." } } For “Least privilege” solution, create a Custom RBAC Role with the below Roles, and assign it to the App Registration Object ID same as above: { "actions": [ "Microsoft.Web/connections/read", "Microsoft.Web/connections/write", "Microsoft.Web/connections/delete", "Microsoft.Web/connections/revokeConnectionKeys/action" ] }How to Access a Shared OneDrive Folder in Azure Logic Apps
What is the problem? A common enterprise automation scenario involves copying files from a OneDrive folder shared by a colleague into another storage service such as SharePoint or Azure Blob Storage using Azure Logic Apps. However, when you configure the OneDrive for Business – “List files in folder” action in a Logic App, you quickly run into a limitation: The folder picker only shows: Root directory Subfolders of the authenticated user’s OneDrive Shared folders do not appear at all, even though you can access them in the OneDrive UI This makes it seem like Logic Apps cannot work with shared OneDrive folders—but that’s not entirely true. Why this happens The OneDrive for Business connector is user‑context scoped. It only enumerates folders that belong to the signed-in user’s drive and does not automatically surface folders that are shared with the user. Even though shared folders are visible under “Shared with me” in the OneDrive UI, they: Live in a different drive Have a different driveId Require explicit identification before Logic Apps can access them How to access a shared OneDrive folder There are two supported ways to access a shared OneDrive directory from Logic Apps. Option 1: Use Microsoft Graph APIs (Delegated permissions) You can invoke Microsoft Graph APIs directly using: HTTP with Microsoft Entra ID (preauthorized) Delegated permissions on behalf of the signed‑in user This requires: Admin consent or delegated consent workflows Additional Entra ID configuration 📘 Reference: HTTP with Microsoft Entra ID (preauthorized) - Connectors | Microsoft Learn While powerful, this approach adds setup complexity. Option 2: Use Graph Explorer to configure the OneDrive connector Instead of calling Graph from Logic Apps directly, you can: Use Graph Explorer to discover the shared folder metadata Manually configure the OneDrive action using that metadata Step-by-step: Using Graph Explorer to access a shared folder Scenario A colleague has shared a OneDrive folder named “Test” with me, and I need to process files inside it using a Logic App. Step 1: List shared folders using Microsoft Graph In Graph Explorer, run the following request: GET https://graph.microsoft.com/v1.0/users/{OneDrive shared folder owner username}/drive/root/children 📘Reference: List the contents of a folder - Microsoft Graph v1.0 | Microsoft Learn ✅This returns all root-level folders visible to the signed-in user, including folders shared with you. From the response, locate the shared folder. You only need two values: parentReference.driveId id (folder ID) Graph explorer snippet showing the request sent to the API to list the files & folders shared by a specific user on the root drive Step 2: Configure Logic App “List files in folder” action In your Logic App: Add OneDrive for Business → List files in folder Do not use the folder picker Manually enter the folder value using this format: {driveId}.{folderId} Once saved, the action successfully lists files from the shared OneDrive folder. Step 3: Build the rest of your workflow After the folder is resolved correctly: You can loop through files Copy them to SharePoint Upload them to Azure Blob Storage Apply filters, conditions, or transformations All standard OneDrive actions now work as expected. Troubleshooting: When Graph Explorer doesn’t help If you’re unable to find the driveId or folderId via Graph Explorer, there’s a reliable fallback. Use browser network tracing Open the shared folder in OneDrive (web) Open Browser Developer Tools → Network Look for requests like: & folderId In the response payload, extract: CurrentFolderUniqueId → folder ID drives/{driveId} from the CurrentFolderSpItemUrl This method is very effective when Graph results are incomplete or filtered.
