Bringing all your Integration workloads to Logic Apps Standard
We recently announced the end of life of BizTalk Server and provided a path forward for our customers. As part of that commitment, we’re investing in tooling and guidance that reduces migration complexity and helps teams modernize confidently to Azure Logic Apps Standard. Because enterprise integration programs are rarely “lift and shift,” we’re pairing automation with best practices, reference architectures, and field-proven guidance to support you from assessment through cutover. In our December 2025 announcement, we outlined a long-term direction for enterprise integration: Azure Logic Apps is the successor to BizTalk Server. Customers can modernize at a pace that balances continuity with innovation—while moving to a cloud platform designed for scale, hybrid operations, DevOps, and AI-assisted automation. The strategy centers on three principles: a predictable BizTalk lifecycle runway, preservation of existing investments, and a practical, guided migration path to Logic Apps. What makes this strategy credible is not just the vision—but the concrete tooling and guidance that back it up. Announcing the Logic Apps Migration Agent: An Open-source project to provide an AI End-to-End Modernization Experience Today we’re announcing the Logic Apps Migration Agent—an open-source Microsoft project that delivers an AI-assisted, end-to-end modernization experience with a structured, stage-gated workflow. Built by the product group and shaped by direct field feedback, the agent operationalizes how migrations should be executed: discover what you have, plan what you’ll modernize, convert incrementally, and validate continuously. The result is a repeatable approach that helps customers (and partners) migrate from BizTalk and other integration platforms to Azure Logic Apps with greater speed and confidence—without compromising governance or correctness. The agent reinforces the modernization strategy through: Discovery → Planning → Conversion: Aligns to Microsoft modernization guidance so teams understand scope, dependencies, and gaps before committing to conversion. Human-in-the-loop checkpoints: Uses AI to accelerate analysis and baseline conversions while enforcing review and approval steps for mission-critical correctness and governance. VS Code + GitHub Copilot integration: Brings migrations into a code-first workflow—enabling developer-centric refactoring, DevOps practices, and consistent implementation patterns for Logic Apps. Incremental, flow-group migration: Modernize one logical unit at a time to reduce risk, support phased cutovers, and avoid big-bang rewrites. Bring-your-own black-box testing: Import existing files, test cases, and specifications to validate behavior and reduce custom test harness work. In short, the Migration Agent turns high-level modernization guidance into a repeatable, auditable process teams can trust. This alignment is critical for customers running mission‑critical integrations. It replaces uncertainty with a clear path: modernize incrementally, reuse what works, validate every step, and emerge on Azure Logic Apps with a platform ready for the next decade of integration and AI-driven automation. What you should focus on? Target architecture decisions: the agent will propose integration patterns, but will not choose partitioning strategy, reliability approach, or network topology—you will decide what “great” looks like. Semantic equivalence: The Agent will generate baseline artifacts, but domain-specific mapping, transformation nuances, error handling semantics, and edge cases still require human validation. Connector and parity gaps must be addressed: if a source platform capability has no 1:1 equivalent, the migration may require redesign (custom code, Local Functions, API Management, Service Bus patterns, or alternative connectors). Performance, security, and operations hardening remain essential: identity, secrets, policies, monitoring, cost controls, and SRE practices are not “one-click.” Cutover planning is outside the scope of automation: data/backlog reconciliation, dual-run strategies, and rollback plans remain project workstreams. 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. Support for local container registry (Hybrid deployment model). 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. For companies providing professional services: this agent is meant to augment your delivery—not replace it. By automating repeatable groundwork (inventory, baseline conversion, and validation scaffolding), it frees your teams to focus on the higher‑value work customers rely on you for: defining target architecture, refining mappings and patterns, hardening security and governance, implementing CI/CD, performance tuning, and driving cutover and operating model changes. Because the project is open source and extensible, partners can also package reusable accelerators (templates, connectors, mapping packs, test harnesses) and build differentiated migration offerings on top of the same trusted process. Review our public documentation here: https://learn.microsoft.com/en-us/azure/logic-apps/migration/migration-agent-overview Check the following video for a demonstration on how the Agent works: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.
Introducing native Service Bus message publishing from Azure API Management (Preview)
We’re excited to announce a preview capability in Azure API Management (APIM) — you can now send messages directly to Azure Service Bus from your APIs using a built-in policy. This enhancement, currently in public preview, simplifies how you connect your API layer with event-driven and asynchronous systems, helping you build more scalable, resilient, and loosely coupled architectures across your enterprise. Why this matters? Modern applications increasingly rely on asynchronous communication and event-driven designs. With this new integration: Any API hosted in API Management can publish to Service Bus — no SDKs, custom code, or middleware required. Partners, clients, and IoT devices can send data through standard HTTP calls, even if they don’t support AMQP natively. You stay in full control with authentication, throttling, and logging managed centrally in API Management. Your systems scale more smoothly by decoupling front-end requests from backend processing. How it works The new send-service-bus-message policy allows API Management to forward payloads from API calls directly into Service Bus queues or topics. High-level flow A client sends a standard HTTP request to your API endpoint in API Management. The policy executes and sends the payload as a message to Service Bus. Downstream consumers such as Logic Apps, Azure Functions, or microservices process those messages asynchronously. All configurations happen in API Management — no code changes or new infrastructure are required. Getting started You can try it out in minutes: Set up a Service Bus namespace and create a queue or topic. Enable a managed identity (system-assigned or user-assigned) on your API Management instance. Grant the identity the “Service Bus data sender” role in Azure RBAC, scoped to your queue/ topic. Add the policy to your API operation: <send-service-bus-message queue-name="orders"> <payload>@(context.Request.Body.As<string>())</payload> </send-service-bus-message> Once saved, each API call publishes its payload to the Service Bus queue or topic. 📖 Learn more. Common use cases This capability makes it easy to integrate your APIs into event-driven workflows: Order processing – Queue incoming orders for fulfillment or billing. Event notifications – Trigger internal workflows across multiple applications. Telemetry ingestion – Forward IoT or mobile app data to Service Bus for analytics. Partner integrations – Offer REST-based endpoints for external systems while maintaining policy-based control. Each of these scenarios benefits from simplified integration, centralized governance, and improved reliability. Secure and governed by design The integration uses managed identities for secure communication between API Management and Service Bus — no secrets required. You can further apply enterprise-grade controls: Enforce rate limits, quotas, and authorization through APIM policies. Gain API-level logging and tracing for each message sent. Use Service Bus metrics to monitor downstream processing. Together, these tools help you maintain a consistent security posture across your APIs and messaging layer. Build modern, event-driven architectures With this feature, API Management can serve as a bridge to your event-driven backbone. Start small by queuing a single API’s workload, or extend to enterprise-wide event distribution using topics and subscriptions. You’ll reduce architectural complexity while enabling more flexible, scalable, and decoupled application patterns. Learn more: Get the full walkthrough and examples in the documentation 👉 here
Migrate Data Ingestion from Data Collector to Log Ingestion
HTTP Data Collector API in Log Analytics workspaces is being deprecated, and will be totally out of support in September 2026. Data Collector actions in logic app using already created API connections (which uses workspace Id & Key) would still work against old custom log tables, however, newly created table will not be able to ingest data, although the connector would still succeed in logic app, but no data will be populated in newly created custom logs. In case new API connection is created for Data Collector action (using workspace Id & Key); these will fail with 403 - Forbidden action. Users should start using the Log Ingestion API to send data to custom tables, and this document will guide users on how to use Log Ingestion API in logic apps. Note: Azure portal currently is update so it doesn't show the Workspace keys in Log Analytics workspace page, however, Az CLI will still get the keys, but as stated, actions will fail with 403 when using them in Data Collector Action. Creating DCE & DCRs: To utilize the Log Ingestion API, Data Collection Endpoint & Data Collection Rule should be created first. DCE Creation is simple, from azure portal search for DCE, and then create a new one: For DCR creation, it can be either created from the DCR page in Azure Portal, or upon creating the custom log in Log Analytics workspace. DCR Popup You need to upload sample data file, so the custom log table has a schema, it needs to be JSON array. In case the sample log doesn't have a TimeGenerated field, you can easily add it using the mapping function as below: Add the below code in the Transformation box, then click run. Once you complete the DCR creation, we need to get the DCE full endpoint. Getting DCE Log Ingestion Full URL To get the full endpoint URL, please follow the below: 1. Get the DCE Log Ingestion URL from the DCE overview page: 2. On the DCR Page, get the immutable id for the DCR., then click on the JSON view of the DCR resource: 3. From the JSON view, get the stream name from the streamDeclarations field Now the full Log Ingestion URL is: DCE_URL/dataCollectionRules/{immutable_id}/streams/{streamName}?api-version=2023-01-01 It would be similar to: https://mshbou****.westeurope-1.ingest.monitor.azure.com/dataCollectionRules/dcr-7*****4e988bef2995cd52ae/streams/Custom-mshboulLogAPI_CL?api-version=2023-01-01 Granting Logic App MI needed IAM Roles: To call the ingestion endpoint using Logic Apps MI, we need to grant logic apps MI the role "Monitoring Metrics Publisher" over the DCR resource. To do this, open the DCR, from the blade choose Access Control (IAM), and then grant the logic app MI the role "Monitoring Metrics Publisher" Calling Log Ingestion Endpoint from logic apps: To call the ingestion endpoint from logic apps, we need to use the HTTP action, as below, the URI is the full DCE Endpoint we created before. Add the content-type headers, and the json body that contains the log data you want to send. For the authentication, it will be as below: Once executed, it should succeed, with status code 204. For more details on the Log Ingestion API, and the migration, please see our documentation: Migrate from the HTTP Data Collector API to the Log Ingestion API - Azure Monitor | Microsoft Learn Logs Ingestion API in Azure Monitor - Azure Monitor | Microsoft Learn Thanks.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" ] }Introducing Skills in Azure API Center
The problem Modern applications depend on more than APIs. A single AI workflow might call an LLM, invoke an MCP tool, integrate a third-party service, and reference a business capability spanning dozens of endpoints. Without a central inventory, these assets become impossible to discover, easy to duplicate, and painful to govern. Azure API Center — part of the Azure API Management platform — already catalogs models, agents, and MCP servers alongside traditional APIs. Skills extend that foundation to cover reusable AI capabilities. What is a Skill? As AI agents become more capable, organizations need a way to define and govern what those agents can actually do. Skills are the answer. A Skill in Azure API Center is a reusable, registered capability that AI agents can discover and consume to extend their functionality. Each skill is backed by source code — typically hosted in a Git repository — and describes what it does, what APIs or MCP servers it can access, and who owns it. Think of skills as the building blocks of AI agent behavior, promoted into a governed inventory alongside your APIs, MCP servers, models, and agents. Example: A "Code Review Skill" performs automated code reviews using static analysis. It is registered in API Center with a Source URL pointing to its GitHub repo, allowed to access your code analysis API, and discoverable by any AI agent in your organization. How Skills work in API Center Skills can be added to your inventory in two ways: registered manually through the Azure portal, or synchronized automatically from a connected Git repository. Both approaches end up in the same governed catalog, discoverable through the API Center portal. Option 1: Register a Skill manually Use the Azure portal to register a skill directly. Navigate to Inventory > Assets in your API center, select + Register an asset > Skill, and fill in the registration form. Figure 2: Register a skill form in the Azure portal. The form captures everything needed to make a skill discoverable and governable: Field Description Title Display name for the skill (e.g. Code Review Skill). Identification Auto-generated URL slug based on the title. Editable. Summary One-line description of what the skill does. Description Full detail on capabilities, use cases, and expected behavior. Lifecycle stage Current state: Design, Preview, Production, or Deprecated. Source URL Git repository URL for the skill source code. Allowed tools The APIs or MCP servers from your inventory this skill is permitted to access. Enforces governance at the capability level. License Licensing terms: MIT, Apache 2.0, Proprietary, etc. Contact information Owner or support contact for the skill. Governance note: The Allowed tools field is key for AI governance. It explicitly defines which APIs and MCP servers a skill can invoke — preventing uncontrolled access and making security review straightforward. Option 2: Sync Skills from a Git repository For teams managing skills in source control, API Center can integrate directly with a Git repository and synchronize skill information automatically. This is the recommended approach for teams practicing GitOps or managing many skills at scale. Figure 3: Integrating a Git repository to sync skills automatically into API Center. When you configure a Git integration, API Center: Creates an Environment representing the repository as a source of skills Scans for files matching the configured pattern (default: **/skill.md) Syncs matching skills into your inventory and keeps them current as the repo changes For private repositories, a Personal Access Token (PAT) stored in Azure Key Vault is used for authentication. API Center's managed identity retrieves the PAT securely — no credentials are stored in the service itself. Tip: Use the Automatically configure managed identity and assign permissions option when setting up the integration if you haven't pre-configured a managed identity. API Center handles the Key Vault permissions automatically. Discovering Skills in your catalog Once registered — manually or via Git — skills appear in the Inventory > Assets page alongside all other asset types. Linked skills (synced from Git) are visually identified with a link icon, so teams can see at a glance which skills are source-controlled. From the API Center portal, developers and other stakeholders can browse the full skill catalog, filter by lifecycle stage or type, and view detailed information about each skill — including its source URL, allowed tools, and contact information. Figure 4: Skills catalog in API Center portal, showing registered skills and the details related to the skill. Developer experience: The API Center portal gives teams a self-service way to discover approved skills without needing to ask around or search GitHub. The catalog becomes the authoritative source of what's available and what's allowed. Why this matters for AI development teams Skills close a critical gap in AI governance. As organizations deploy AI agents, they need to know — and control — what those agents can do. Without a governed skill registry, capability discovery is ad hoc, reuse is low, and security review is difficult. By bringing skills into Azure API Center alongside APIs, MCP servers, models, and agents, teams get: A single inventory for all the assets AI agents depend on Explicit governance over which resources each skill can access via Allowed tools Automated, source-controlled skill registration via Git integration Discoverability for developers and AI systems through the API Center portal Consistent lifecycle management — Design through Production to Deprecated API Center, as part of the Azure API Management platform and the broader AI Gateway vision, is evolving into the system of record for AI-ready development. Skills are the latest step in that direction. Available now Skills are available today in Azure API Center (preview). To register your first skill: Sign in to the Azure portal and navigate to your API Center instance In the sidebar, select Inventory > Assets Select + Register an asset > Skill Fill in the registration form and select Create → Register and discover skills in Azure API Center (docs) → Set up your API Center portal → Explore the Azure API Management platform
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.New Azure API management service limits
Azure API Management operates on finite physical infrastructure. To ensure reliable performance for all customers, the service enforces limits calibrated based on: Azure platform capacity and performance characteristics Service tier capabilities Typical customer usage patterns Resource limits are interrelated and tuned to prevent any single aspect from disrupting overall service performance. Changes to service limits - 2026 update Starting March 2026 and over the following several months, Azure API Management is introducing updated resource limits for instances across all tiers. The limits are shown in the following table. Entity/Resource Consumption Developer Basic/ Basic v2 Standard/ Standard v2 Premium/ Premium v2 API operations 3,000 3,000 10,000 50,000 75,000 API tags 1,500 1,500 1,500 2,500 15,000 Named values 5,000 5,000 5,000 10,000 18,000 Loggers 100 100 100 200 400 Products 100 100 200 500 2,000 Subscriptions N/A 10,000 15,000 25,000 75,000 Users N/A 20,000 20,000 50,000 75,000 Workspaces per workspace gateway N/A N/A N/A N/A 30 Self-hosted gateways N/A 5 N/A N/A 100 1 1 Applies to Premium tier only. What's changing Limits in the classic tiers now align with those set in the v2 tiers. Limits are enforced for a smaller set of resource types that are directly related to service capacity and performance, such as API operations, tags, products, and subscriptions. Rollout process New limits roll out in a phased approach by tier as follows: Tier Expected rollout date Consumption Developer Basic Basic v2 March 15, 2026 Standard Standard v2 April 15, 2026 Premium Premium v2 May 15, 2026 Limits policy for existing classic tier customers After the new limits take effect, you can continue using your preexisting API Management resources without interruption. Existing classic tier services, where current usage exceeds the new limits, are "grandfathered" when the new limits are introduced. (Instances in the v2 tiers are already subject to the new limits.) Limits in grandfathered services will be set 10% higher than the customer's observed usage at the time new limits take effect. Grandfathering applies per service and service tier. Other existing services and new services are subject to the new limits when they take effect. Guidelines for limit increases In some cases, you might want to increase a service limit. Before requesting a limit increase, note the following guidelines: Explore strategies to address the issue proactively before requesting a limit increase. See the article here Manage resources within limits. Consider potential impacts of the limit increase on overall service performance and stability. Increasing a limit might affect your service's capacity or increase latency in some service operations. Requesting a limit increase The product team considers requests for limit increases only for customers using services in the following tiers that are designed for medium to large production workloads: Standard and Standard v2 Premium and Premium v2 Requests for limit increases are evaluated on a case-by-case basis and aren't guaranteed. The product team prioritizes Premium and Premium v2 tier customers for limit increases. To request a limit increase, create a support request from the Azure portal. For more information, see Azure support plans. Documentation For more information, please see documentation here
