Add AI to the workflows you already have using Serverless Agents in Azure Functions
There are a lot of ways to build with AI right now: chat frontends, copilots, greenfield agent apps, orchestration frameworks. All of them have their place, and some customers are building entirely new applications this way. But across customer engagements, a consistent pattern has emerged: the most successful and most cost-effective AI projects are not rewrites. They are existing, deterministic, event-driven business workflows (queue processing, message handling, scheduled jobs) with AI added at exactly the one step that was never deterministic to begin with. This enables the parts that are battle hardened to remain as before, adding AI where non-deterministic smarts are needed. This creates a more robust application along with spending costs for tokens only where beneficial. That pattern has a natural home in Azure Function and Serverless Agents runtime now support non-Http triggers. This post walks through the pattern in three layers: the app you already have, what it takes to add AI processing onto it yourself, and what it looks like with Serverless Agents. Learn and try it here: Build serverless agents using Azure Functions | Microsoft Learn The scenario: expense processing Picture an expense approval pipeline. Expense and purchase-order requests arrive as messages on a queue: some as quick notes, some as forwarded emails, some as key-value text or JSON from intake tools. Most of the piping around the decision is deterministic and should stay that way: queueing, retries, policy storage, output queues, identity, and the audit trail. You do not want a language model reimplementing any of that. But one step in the middle has always resisted automation: understanding the request, choosing the policy that governs it, and applying a natural-language rulebook. "Booked a $450 round-trip flight to Denver for the customer onsite next week. — Albert" Turning that into a structured decision (amount, currency, vendor, category, policy applied, destination queue, reason) is exactly the kind of fuzzy, judgment-shaped work that used to mean either a human in the loop or a brittle pile of regexes and keyword lists. That one step is the AI part of the equation. Everything else stays as code. Layer 1: the app you already have If you're running message-based workloads on Azure Functions today, your expense processor looks something like this, using the standard Python v2 programming model with a queue trigger: import json import azure.functions as func app = func.FunctionApp() @app.queue_trigger(arg_name="msg", queue_name="expense-requests", connection="AzureWebJobsStorage") def process_expense(msg: func.QueueMessage): expense = json.loads(msg.get_body()) validate_expense(expense) if is_duplicate(expense): return decision = apply_expense_policy(expense) route_decision(decision) write_audit_record(expense, decision) This is good architecture, and nothing in this post asks you to change it. You get scale-out per message, retries with a poison queue after repeated failures, and scale to zero between messages. On the Flex Consumption plan you pay for execution, not for idle. The queue itself is doing real architectural work: it buffers spikes, absorbs backpressure, and decouples producers from processing. The limitation is only that process_expense can read only the schema for which it was written. Free text, email-shaped messages, and inconsistent key-value input require a parser before the deterministic policy code can use them, and selecting among category-specific policy documents means encoding more rules in code. Layer 2: the do-it-yourself middle step The obvious next move is to call a model from inside the function. The first version is deceptively short: # Sketch of the DIY approach: this is the version that grows client = get_model_client() # SDK setup, endpoint, credential prompt = build_prompt(expense) # prompt template you now maintain response = client.complete(prompt) # plus retry/backoff for 429s decision = parse_or_die(response) # LLM output isn't always valid JSON The problem isn't the first version. It's everything the first version turns into. Model SDK and auth wiring. Prompt templates living in Python strings. Retry and backoff logic for rate limits, on top of the queue's own retry semantics. Output parsing and re-prompting when the model returns almost-JSON. Then the requests start arriving: "can it look up the current policy documents?" (now you are building tool-calling), "can it run a calculation?" (now you need somewhere safe to execute generated code), "why did it say that?" (now you are building telemetry for model and tool activity). None of this is your expense pipeline. All of it becomes your code to own, patch, and secure. This is the middle step where a lot of AI-in-the-workflow projects stall, not because the idea was wrong, but because the glue outgrew the feature. Layer 3: the same trigger, with the Serverless Agents runtime The Serverless Agents runtime, collapses that middle layer. An agent is a markdown file, with instructions in the body and the trigger in YAML front matter, and it runs on the same Azure Functions triggers you already use. Here is the complete agent from the expense processor sample, expense_processor.agent.md: --- name: Expense Processor description: Reads one expense or purchase-order request that arrives on a queue in any format — free text, email, key-value, or JSON — chooses the spending policy that fits the expense category from a set of policy documents, applies it, and routes the decision. trigger: type: queue_trigger args: queue_name: expense-requests connection: AzureWebJobsStorage data_type: string --- You are an expense-approval agent. Each queue message is **one** expense or purchase-order request as raw text — it might be a quick note, an email, `key: value` lines, or JSON. Finance keeps several policy documents in storage: a general policy plus category-specific ones (travel, meals & entertainment, equipment & software). Your job is to understand the request, pick the policy that governs it, and route the decision. For each message: 1. **Extract** the details, whatever the format: `amount` (strip symbols, separators, and words — `$1,250`, `1.250,00`, and `twelve hundred dollars` are all numbers), `currency` (default `USD`), `vendor`, `category`, and an `expenseId` (use the one in the message, else generate `EXP-<6 hex>`). 2. **Select the policy.** Call `list_expense_policies` to see each policy and what it covers, then choose the one whose scope matches the expense. Use the general policy when nothing else fits. 3. **Fetch it.** Call `get_expense_policy` with that document's exact name, and apply what it says. 4. **Decide.** Work the policy's rules top to bottom; the first rule that matches wins. The amount is the backbone — for an ordinary in-scope USD expense the policy's amount thresholds decide the outcome, applied exactly at the boundaries. Never guess an exchange rate for a non-USD amount. The result is one of three queues: `expense-approved`, `expense-review`, or `expense-flagged`. 5. **Route** by calling `route_expense_decision` **once** with the destination queue and the decision JSON. If it errors, carry on — still return the decision. 6. **Respond** with the decision JSON so the outcome shows up in the logs: ```json { "expenseId": "EXP-1001", "vendor": "United Airlines", "category": "travel", "amount": 450.0, "currency": "USD", "policyApplied": "travel-policy.md", "decision": "approve", "routedTo": "expense-approved", "reason": "Travel expense of 450 USD is at or below the travel policy's 1,000 auto-approve threshold." } ``` Base every decision only on the policy you just fetched — never on rules remembered from an earlier message. Keep `reason` to one sentence, and always set `policyApplied` to the document you used. Note what the front matter is: the same queue_trigger configuration you would pass to the Functions decorator: queue name, connection setting, and string data type. If you know Azure Functions triggers, you already know how to trigger an agent. The entire function_app.py is bootstrap: from azure_functions_agents import create_function_app app = create_function_app() And app-wide defaults live in agents.config.yaml: # App-wide defaults for every agent in this function app. # # `model` is intentionally NOT set here so the runtime resolves it per provider: # - deployed (foundry provider): FOUNDRY_MODEL app setting (e.g. gpt-5.4) # - local (azure_openai provider): AZURE_OPENAI_DEPLOYMENT setting (e.g. gpt-5.4-mini) # Set AZURE_FUNCTIONS_AGENTS_MODEL to override in any environment. timeout: 900 When a message lands on expense-requests, the runtime invokes the agent once for that one item. The trigger's data_type: string and the host's messageEncoding: "none" keep the raw text human-readable, while the runtime serializes the queue message body and metadata before adding them to the agent prompt. The agent's instructions do fuzzy work; the results show up in your Function App logs and Application Insights like any other execution. For the expense scenario, the pattern points directly at the intake queue: the agent extracts the amount, currency, vendor, category, and expense ID; calls list_expense_policies and get_expense_policy to choose and read the current policy from Blob Storage; applies the rules; and calls route_expense_decision to send the result to expense-approved, expense-review, or expense-flagged. Queueing, policy storage, identity, and routing stay deterministic; the agent gets responsibility for the part that needs judgment. What changed between layer 2 and layer 3 Concern DIY (layer 2) Serverless Agents (layer 3) Trigger & scaling Yours (Functions) Yours (Functions, unchanged) Model client, auth, provider config Your code Runtime (Foundry, Azure OpenAI, or OpenAI) Prompt & instructions Python strings Markdown agent file Trigger payload handling Manual parsing Raw queue payload and metadata injected by the runtime Tool calling Build it yourself MCP servers, connectors, plain-Python @tool functions Safe code execution Build it yourself Sandboxed via Azure Container Apps dynamic sessions Model/tool telemetry Build it yourself Built-in, flows to Application Insights Retries & poison handling Queue semantics + your model retries Queue semantics, with dequeue_count right in the payload The economics follow from the architecture. On Flex Consumption, the app scales to zero between messages, so you pay when expense requests arrive, and the AI spend is confined to the single step that needs a model, instead of being architected into every request the way a chat-first design tends to force. This is a large part of why the augment-don't-rewrite engagements are the cost-effective ones: the deterministic 90% of the workload keeps running at deterministic-workload prices. Use all Event Driven triggers Queue Trigger is one row in a much longer table. The runtime supports the breadth of the Functions trigger model in .agent.md front matter: Service Bus queues and topics, Event Hubs, Event Grid, Blob Storage, Cosmos DB, Azure SQL, Kafka, timers, Dapr bindings, and connector triggers, alongside HTTP when you do want a chat endpoint. Wherever your events are already flowing, an agent can meet them there. Try it The sample deploys with the Azure Developer CLI: git clone https://github.com/Azure-Samples/serverless-agents-expense-processor.git cd serverless-agents-expense-processor azd up Then send one of the bundled requests to the provisioned expense-requests queue and read the decision queues: uv run scripts/send_expense.py --file samples/travel.txt --cloud uv run scripts/read_decision.py --queue all --peek --cloud The travel request is a $450 flight. Swap samples/travel.txt for samples/client-dinner.txt or samples/equipment.txt to see the same amount, select a different policy and route differently. The sample's README also covers running locally with Azurite and Core Tools. We are working on many more features to make it really easy for you to take your existing apps and make them intelligent, including Hybrid AI apps (your code + AI markdown binding), dynamic workflows and so on.
Azure App Service secure hostname
Hey Everyone, I see a new change in app service deployment related to the secure hostname. Is it now mandatory to have a secure hostname, because I don't see the option to toggle between the secure hostname and just the format for appservicename.azurewebsites.net ? I wasn't able to find any update notification to verify this change.How to build long-running MCP tools on Azure Functions
Recently, a customer building servers with the Azure Functions MCP extension reached out and asked: How do I handle tools that take longer than the client is willing to wait? This becomes especially relevant when tool calls move beyond simple request/response into multi-step workflows and long-running operations. At the same time, MCP is evolving to address exactly this. The Tasks extension is introduced in the 2026-07-28 release candidate, defining a standard way to model long-running work. In this post, we’ll walk through how to build long-running MCP tools on Azure Functions using Durable Functions , a framework for authoring stateful, long-running workflows as ordinary code, with checkpointing, scaling, and recovery handled automatically. MCP tools today Today, MCP tools are fundamentally request/response: the client issues a tools/call the server returns a result This works well for fast operations, but breaks down when: workflows take minutes execution depends on multiple steps latency is unpredictable In practice, clients enforce their own tool-call timeouts. These aren't standardized by the MCP spec and vary per client, but they're often in the ~30–60 second range. If a tool exceeds that window: In practice, clients often enforce short timeouts. If a tool exceeds that window: the client times out the agent observes a failed call the underlying work may still be running So the core issue is that you have synchronous tool calls don’t naturally model long-running work. The MCP Tasks extension The Tasks extension to address this. With the extension, a server can respond to a tools/call with an asynchronous task handle instead of a final result, and the client drives the lifecycle from there: tasks/get: poll the task's status tasks/update: submit input back to the server if the task reaches input_required tasks/cancel: cancel an in-flight task A task carries a status ("working", "input_required", "completed", "failed", or "cancelled") and on completion, the final result. Task creation is server-directed: the client advertises support by including the extension in its per-request capabilities, and the server decides per request whether to return a task. A server won't return a task to a client that hasn't advertised support. It's important to note that Tasks rely on ecosystem support. Clients must advertise the extension, and MCP SDKs must implement the task lifecycle, before servers can use it. So while Tasks is now a defined extension, broad client and SDK support is still in progress. Implement long-runng tasks with Durable Functions today Until the Tasks extension is broadly supported across clients, we need a pattern that works with existing request/response clients and supports long-running execution. The following samples show how, using Durable Functions: Python NET The long-running work in this sample mines a short chain of blocks. Each block requires solving a computational puzzle where the system keeps trying different inputs until it finds one that produces a result matching a specific pattern (for example, starting with a certain number of zeros). Because this involves lots of trial and error, it naturally takes time, making it a good example of a long-running workflow. The server in the sample exposes two tools: start_mining Starts a Durable Functions orchestration to mine the blocks Waits briefly (within a configurable budget) Returns result inline if completed within budget OR returns workflow_id if still running get_mining_result Takes the workflow_id Returns the current state, e.g. "completed", "running", "failed", or "not_found" To ensure that the agent calls the tools in the right order, workflow_id is a required parameter of get_mining_result, so the agent can't poll without starting a mining run first. Also, the "running" response carries a poll_after_seconds and a next instruction, ensuring the agent to poll again if work is not done rather than give up or assume completion. Even so, the poll path still relies on the agent correctly remembering, and not hallucinating, the workflow_id it was handed. If it garbles or invents an id, the poll lands on the wrong instance or none at all (which is why get_mining_result returns "not_found" rather than guessing). What changes with the Tasks extension Once the Tasks extension is fully implemented across clients and SDKs, the model becomes simpler and more reliable: the server returns a Task handle, the client manages the polling and lifecyle calls, and the SDK tracks execution state. This removes a key limitation of today’s solution, which requires the agent to remember and correctly pass identifiers like workflow_id. Call to action Try out the sample and let us know whether it addresses your MCP needs around long-running or workflow type tools!VNet integration for Azure SRE Agent (preview)
For many production systems, the logs, databases, private endpoints, repositories, and runbooks an SRE Agent needs to do its job are behind network boundaries your security team already governs. VNet integration for Azure SRE Agent, now in preview, puts the agent's outbound traffic under those same controls - your virtual network, your NSG rules, your private DNS - so it reaches only what your network allows. The principle is one your security team already applies to every other workload: a component's network access shouldn't depend on the component behaving correctly. Identity governs what the agent can reach. Permissions and hooks shape what it does within reach. The network sits beneath both: it blocks any request to a destination you haven't allowed no matter what the agent decides. Why egress control matters Two reasons. First, the agent reads sensitive things by design. Inspecting logs, code, configuration, and internal systems is the whole point during an incident, which means you have to decide where that data can go. Open egress gives that data a path out of your network - a risk you wouldn't accept for any other production-adjacent workload. Second, it reasons over text it didn't write - logs, issue descriptions, tool output — which is how prompt injection gets in. Handling that is partly model safety, and Azure SRE Agent runs under Microsoft's Responsible AI standard with safety work from OpenAI and Anthropic. Network controls add another layer: an instruction that tries to reach a destination you haven't allowed can't run, because the network blocks it. For example, an agent investigating an outage might query Log Analytics, read deployment configuration, and call an internal runbook - all private resources. With VNet integration, those calls follow the routes, DNS, and firewall rules your workloads already use. A request to an external endpoint you haven't allowed fails at the network boundary. It doesn't depend on the model recognizing the risk and refusing; the network stops it either way. Choose an egress mode Azure SRE Agent has three egress modes, and you don't have to start at the strongest. Unrestricted - all outbound traffic allowed Limited - deny all outbound, allow an explicit list of hosts. Gives you host-level control without setting up a full VNet Azure VNet - outbound traffic goes through a delegated subnet in your network, with your NSG rules and private DNS applied. The recommended mode for production and regulated workloads. How Azure VNet mode works Outbound traffic takes one of two paths, and every call takes exactly one. Your VNet. Everything not placed on the managed path goes through a delegated subnet in your own network, where your NSG rules, private DNS, and firewall all apply. The agent is just another workload on that subnet, so it can reach what the subnet can reach: databases behind private endpoints, internal services, monitoring stores, and key vaults -the parts of production that aren't reachable from the public internet. The resources that matter most during an incident are usually the private ones. If your network connects to on-premises over ExpressRoute or VPN, the agent can reach those systems too, as long as your existing routes and rules allow it. The managed infra path. Some destinations go through Azure SRE Agent's managed infrastructure network instead - platform services the agent needs, plus optional categories you turn on: package registries, code repositories, and remote MCP servers. This path skips your VNet, so your NSG rules and Firewall Policies don't apply to it. Treat it as a deliberate exception, used only where you need it. Why public services start on the managed path Public services are hard to allow by IP address. GitHub, PyPI, npm, NuGet, apt, and the container registries run on large, changing IP ranges, and they don't map to a single Azure service tag. If your NSG filters by IP and port, keeping those lists up to date is constant work, and when a list falls behind, the agent can't pull a package or read a repository - and an investigation stalls on a networking problem that has nothing to do with the incident. Each category has a toggle: package registries (PyPI, npm, NuGet, apt), code repositories (GitHub, GitHub Enterprise, Azure DevOps), remote MCP servers, and a list of additional hostnames. Starting with these on the managed path keeps the agent working reliably without maintaining an IP allowlist. For build-time dependencies, that's usually fine. If you want this traffic inspected too, the next step is name-based (FQDN) egress filtering in your own network. Once your firewall can allow github.com and pypi.org by name, you can move these categories off the managed path and route them through your VNet instead Configure it Two decisions: the subnet, and what (if anything) uses the bypass. Navigate to Settings > Workspace Configuration > Network Choose Azure VNet as the egress mode. Select a subnet that is /27 or larger and delegated to `Microsoft.App/environments`. Decide which categories, if any, use the bypass. Restrict who can change the egress mode and bypass toggles. These settings widen or narrow the agent's reach, so govern them like any production network control. Test the outbound behavior before using the agent with production data. A reasonable setup for most enterprises during preview: use Azure VNet mode, keep package registries and code repositories on the bypass if you need reliable access to them, and route everything else through your VNet. Stricter environments can turn those categories off and rely on their own name-based firewall rules. What it doesn't cover yet VNet integration is in preview, with two limitations to know. It covers outbound traffic only - reaching the agent privately from inside your network isn't part of this preview. And connector traffic still routes over the public internet; the governance and credential isolation in Connectors V2 still apply. Use VNet integration for outbound control of the agent workspace, and combine it with identity, RBAC, tool permissions, hooks, and connector governance for a complete set of controls. Where it fits VNet integration doesn't replace identity, RBAC, tool permissions, or connector governance. It controls where traffic can go. The agent still needs the right identity and permissions to access a resource in the first place. Identity is the foundation: your RBAC assignments decide what the agent can reach. Permissions and hooks shape what it does within reach: allow/ask/deny rules control what runs, and hooks let you inspect or change a tool call before it runs. VNet integration sits underneath, controlling where traffic can go no matter what the agent tries to do. You want the agent to be capable. You also want a boundary that holds whether or not it is. Get started Create an SRE Agent - https://aka.ms/sreagent Documentation - https://aka.ms/sreagent/newdocs Recipes - https://aka.ms/sreagent/recipes Build 2026 Announcement - https://aka.ms/Build26/blog/SREAgentPrivate Plugins with Azure SRE Agent
SRE's and platform teams are building operational skills specific to their infrastructure: investigation runbooks, compliance checks, cost analysis playbooks, deployment verification procedures. The next step is making that work reusable across every agent in the organization without exposing it publicly. Today, SRE Agent supports plugin marketplaces hosted in private GitHub repositories, including GitHub Enterprise. This is part of the Azure SRE Agent announcements at Build 2026. You can now point SRE Agent at a private repo when adding a marketplace or installing a plugin. Authentication is handled per-marketplace, and supports OAuth, GitHub PATs, and GitHub Apps for GHE tenants. From one agent to an organization’s plugin catalog Most teams start with a single SRE Agent connected to their services. The agent learns their infrastructure, runs their runbooks, and handles their incidents. It works well. Then adoption grows. A second team stands up their own agent. Then a third. Platform engineering wants every agent to run the same compliance checks. Security needs approval hooks enforced consistently. FinOps has cost governance skills that should be standard across the organization. Suddenly the question isn’t “how do I set up my agent,” it’s “how do we share operational knowledge across all of them.” Without a distribution model, teams end up copying skill files between agents manually. A platform team writes a runbook, shares it over email or a wiki link, and each service team pastes it into their agent individually. When the runbook improves, some agents get updated, some don’t. There’s no version tracking, no central catalog, and no way to know which agent is running which version of which skill. Private marketplace support solves this. How Private Plugin marketplace meet enterprise needs A platform team publishes once, every agent installs. Codify best practices as plugins in a private GitHub repo. Service teams add that repo as a marketplace in their agents and install what they need. Compliance checks, cost governance thresholds, incident playbooks, deployment verification procedures all distributed through versioned plugins. Each team retains ownership. Security controls which plugins enforce approval hooks. FinOps locks cost thresholds into parameter values. Platform engineering governs infrastructure investigation patterns. The marketplace is the distribution layer for organizational standards. Versions are pinned, updates are explicit. Each installation locks to the commit at install time. A merged PR upstream does not change any agent’s behavior. Teams promote new versions on their own schedule: validate in dev, promote to staging, then production. Different agents can run different versions simultaneously. Reuse across environments and tools. The same plugin works across dev, staging, and production agents, and can be reused by local coding agents and other services that support plugins. One source of truth, not separate copies per environment. Accessing Private Plugin marketplaces Private repo support adds authentication to the SRE Agent's plugin workflow so your agent can clone and install from repos that require credentials. Authentication is configured once per marketplace. Every plugin within it inherits the credentials. Auth method When to use Setup OAuth github.com repos your agent can already access Uses your existing GitHub connection. One click. Personal access token Private repos in other orgs on github.com Per-marketplace PAT. Scoped to just that marketplace. GitHub App GitHub Enterprise (*.ghe.com) BYO App with private key in Azure Key Vault. Short-lived tokens minted at runtime. Getting started In SRE Agent, navigate to Builder > Plugins, then click Add Marketplace and enter the URL of the private marketplace you want to connect to. Then click Connect to GitHub to complete the OAuth sign-in. Click Add and you will see the plugins available from your connected marketplace. Click on the plugin to install and in the detail view you can browse the skills packaged with the plugin. click Install to install this plugin. You can now see the skills imported from plugins from Capabilities > Skills > Custom Skills The bottom line Private repo support turns the Plugin Marketplace from a public skill catalog into your organization’s internal distribution platform for operational automation. Your team writes the plugins. Your agents install them. Your GitHub permissions control who has access. Try it yourself: create a private repo with a marketplace.json and a few skills, add it as a marketplace in your agent, and install a plugin. Resources SRE Agent documentation — https://aka.ms/sreagent/newdocs SRE Agent overview — https://aka.ms/sreagent/newdocsoverview Plugin Marketplace capability page — https://aka.ms/sreagent/newdocs/capabilities/plugin-marketplace Build 2026 SRE Agent announcements - https://aka.ms/Build26/blog/SREAgentAzure Functions at Build 2026 Update
Azure Functions took another big leap at Build 2026. It is now the best programming model for event-driven apps and agents, on the best infrastructure to write secure code that scales. The headline features: serverless agents, connectors to M365, Teams, and more, Go, MCP, and Durable Tasks. Microsoft Copilot scales AI workflows to hundreds of millions with Durable Task Scheduler Before we start with all the announcements, we want to highlight a new case study. As Microsoft Copilot scaled to support complex, long-running AI workflows, engineering teams needed a more reliable and consistent orchestration model. By standardizing on Durable Task Scheduler in Azure Functions, Copilot unified state management, retries, and recovery across services, helping run hundreds of millions of executions weekly while improving resilience and delivery speed. Read the customer story: https://aka.ms/microsoft-copilot-dts Serverless agents runtime (Preview) → Full post Azure Functions now has a first-class programming model for AI agents. Define an agent in a .agent.md file with markdown instructions plus metadata that declares the trigger and tools, and deploy it exactly like any other Function. No framework to wire up, no hosting infrastructure to manage. Any Azure Functions trigger can run an agent: HTTP, Timer, Service Bus, Event Hubs, SQL Database, Cosmos DB, or the new connection-backed triggers (Teams message, Outlook mail, calendar events, SharePoint item). Agents get access to MCP tool servers, sandboxed code and browser execution via Azure Container Apps dynamic sessions, and the full 1,400+ connector catalog. Built-in surfaces like chat UI, HTTP chat API, and MCP server endpoint are opt-in with no extra code. The operational model is exactly what you already know: Flex Consumption for scale-to-zero and per-second billing, managed identity for auth, Application Insights for traces, azd for deployment. Here's a timer-triggered agent that summarizes the day's tech news and emails it: --- name: Daily Tech News Email description: Fetches top tech news and emails a summary daily. trigger: type: timer_trigger args: schedule: "0 0 15 * * *" --- You are a news assistant. When triggered, do the following: 1. Scour the web for today's top tech news headlines. Use reputable sources; Include links to the original articles. 2. Summarize the top stories in a concise, well-formatted HTML email body. 3. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary" followed by today's date. That's the whole function! Managed connectors (Preview) → Full post Azure Functions now includes the same 1,400+ managed connectors behind Logic Apps and Power Platform as first-class triggers in your Functions code, plus typed SDKs for invoking connector actions from your function body. Built jointly with the Connectors team on the new Connector Namespace service, so connectors feel native to Functions and the library that already powers thousands of Logic Apps workflows is now available to Functions developers. React to SaaS events with first-class triggers like Office 365 new-email, Teams message-posted, SharePoint item-created, Dataverse row-changed, Salesforce record-updated, calendar events, and more using the [ConnectorTrigger] attribute. Call connector actions from your code via strongly-typed clients like OutlookClient, TeamsClient, Office365UsersClient, DataverseClient, and SalesforceClient. public class ProcessEmail(TeamsClient teams) { [Function("OnNewEmail")] public async Task Run([ConnectorTrigger] Office365OnNewEmailTriggerPayload payload) { foreach (var email in payload.Body?.Value ?? []) { await teams.PostMessageToConversationAsync("Flow bot", "Channel", new PostMessageRequest { Recipient = new() { GroupId = _teamId, ChannelId = _channelId }, MessageBody = $"<b>New email</b> from {email.From}: {email.Subject}" }); } } } MCP updates → Full MCP extension post The Azure Functions MCP extension now covers all the MCP primitives like tool, resource, and prompt triggers are supported in .NET, Java, Python, TypeScript, and JavaScript. The extension also supports MCP Apps for interactive UI, where your tools can return rendered widgets instead of plain text. And for .NET developers, a new fluent builder API makes it easier to compose MCP servers by chaining tool and resource definitions in a declarative style: builder.ConfigureMcpTool("sayhello") .WithProperty("name", McpToolPropertyType.String, "Name of the user", required: true) .WithMetadata("ui", new { resourceUri = "ui://index.html" }); Finally, Built-in MCP authentication now offers a one-click configuration experience in the Azure portal, and a new AI tab in your function app lets you enable MCP auth without manual app registration or wiring. New Azure Functions CLI (Preview) V5 is here! A ground-up, next-gen build of the Azure Functions CLI. Now in public preview this release gives local Functions development a refresh. Configuration profiles let you define your deployment targets up front, so func init can scaffold a project with full‑fidelity host settings in a single command. That means no more surprises when you deploy, earlier access to new platform capabilities, and improved reliability across environments. New func setup preps your machine for .NET, Node, Python, or Go in one command. The func quickstart command scaffolds complete, ready-to-run apps from a curated catalog. And a new interactive func run dashboard gives you a live TTY UI with a function browser, log navigation, and keyboard shortcuts. Existing func workflows for create, run, publish, and deploy carry forward unchanged, so you can try v5 alongside your current projects. Give it a spin and let us know what you think. Full command reference: Azure Functions local runtime and tools reference (v5) Azure Functions VS Code Template Gallery (Preview) The latest version of the Azure Functions extension for VS Code introduces a new Template Gallery, giving you single-click access to complete, ready-to-deploy templates. The gallery is hand-curated and maintained by the Functions team to keep every template aligned with the latest releases and best practices, including Azure Developer CLI (AZD) enablement and recommended settings. It already covers the majority of supported languages and triggers, and will continue to expand with the newest Azure Functions features. The same templates are available across both VS Code and the new Functions CLI (func quickstart). Go language support (Preview) → Full post Azure Functions now supports Go as a first-class language, available on Flex Consumption. The programming model is code-first and idiomatic: HTTP handlers are plain http.HandlerFunc, non-HTTP triggers take a context.Context and a typed payload, and the project layout is a standard Go module. Go build, go test, and go mod tidy just work. package main import ( "fmt" "net/http" "github.com/azure/azure-functions-golang-worker/sdk" "github.com/azure/azure-functions-golang-worker/worker" ) func main() { app := sdk.FunctionApp() app.HTTP("hello", hello, sdk.WithMethods("GET", "POST"), sdk.WithAuth("anonymous"), ) worker.Start(app) } func hello(w http.ResponseWriter, r *http.Request) { name := r.URL.Query().Get("name") if name == "" { name = "world" } fmt.Fprintf(w, "Hello, %s!", name) } Triggers in preview: HTTP, Timer, Service Bus, Event Hubs, Event Grid, Cosmos DB, and Blob Storage. No function.json, no interop shims, no generated metadata to keep in sync. On-demand Sandboxes for Durable Task Scheduler (Private Preview) → Full post Move individual orchestration steps to managed, isolated compute while your orchestrator stays exactly where it is. Declare which activities should run as serverless, point at a container image, and DTS handles provisioning, scaling, and teardown. No infrastructure to manage, no idle costs, no orchestrator changes. Each execution runs in a clean, microVM-backed sandbox with per-activity or per-invocation isolation, ideal for native toolchains (ffmpeg, LibreOffice, Pandoc), CPU-heavy preprocessing (OCR, image work), cross-runtime steps (a Python inference activity called from a .NET orchestrator), sandboxed execution of customer plugins or LLM-generated code, and bursty workloads that can't justify always-on infrastructure. Sign up for On-demand Sandboxes Private Preview Today → Azure Functions Skills for coding agents (Preview) → Full post Bring Azure Functions expertise to your coding agent. Azure Functions Skills equips GitHub Copilot CLI, Claude Code, and Codex with Functions-specific knowledge like trigger and binding patterns, language anti-patterns, runtime versions, and deployment best practices, so your agent gives accurate guidance instead of generic advice. One command installs guided workflows to create, deploy, diagnose, and review Functions apps. The standout is the doctor command: it uses LLM-powered semantic analysis to catch configuration mistakes and code issues like missing error handling, blocking I/O, hardcoded secrets, durable-orchestrator non-determinism, and supply-chain risks before you deploy, available as both a local CLI command and a GitHub Actions pre-deploy gate. Try it now! npx @azure/functions-skills install Built-in Grafana dashboards (Generally available) Every function app now has a single pane of glass for operations with zero setup. A new Grafana dashboards entry in the function app's portal TOC opens a prebuilt dashboard purpose-built for Functions: execution count, success/failure rates, p50/p95/p99 duration, resource utilization, scale activity, and recent errors linked to Application Insights logs all in one view, scoped to your app. It's powered by Azure Monitor managed Grafana, so there's nothing to provision, wire up, or pay extra for. Duplicate and customize it to make it your own, save it to your subscription, and share it with your team. Start using built-in Grafana Dashboards today! TLS/SSL certificate support Flex Consumption (Preview) Azure Functions Flex Consumption now supports TLS/SSL certificates through a new site-scoped certificate model in public preview. Each function app can hold up to 3 private (.pfx) and 3 public (.cer) certificates uploaded directly, imported from Azure Key Vault, or issued as free App Service Managed Certificates to enable custom domains, client-certificate authentication, and mutual TLS scenarios on Flex Consumption. See Configure site-scoped certificates, infrastructure as code instructions, and the cross-plan certificate comparison for details. Rolling Updates for Flex Consumption (Generally Available) Rolling updates are now generally available in the Flex Consumption plan, delivering zero-downtime deployments with a simple configuration change. Instead of forcefully restarting all instances during code or configuration updates, the platform gracefully replaces live instances by draining batches every few seconds while dynamically scaling out the latest version to meet demand. This approach ensures uninterrupted execution and resilient throughput across HTTP, non-HTTP, and Durable workloads - even during intensive scale-out scenarios. Learn more at Site update strategies in Flex Consumption. OS-level dependencies with containers on Flex Consumption (coming soon) Bring your own OS-level dependencies to Flex Consumption without giving up serverless. Package your Functions worker and app code as a container image with a standard Dockerfile (Chromium for Playwright, native toolchains, custom system libraries, whatever your app needs) and run it on the Flex Consumption plan. You get the things that make Flex valuable: dynamic, event-driven scaling across all triggers and the pay-per-execution billing model. This is expected in the next couple of months. Sign up to get early access and updates → How to engage Everything announced this week is being actively shaped by real workloads. We want to hear from you. X (Twitter): http://x.com/azurefunctions Microsoft Q&A: file issues and track progress at https://learn.microsoft.com/en-us/answers/questions/ask/Shaping what Azure SRE Agent does: Tool Permissions and Hooks
When an AI agent runs against production, the first question every security team asks is "What can it do, who decided it could, and what stops it from doing something it should not." Azure SRE Agent reached general availability in March. Since then, teams inside Microsoft and customers running it against real production workloads have asked for the same thing: finer-grained controls over what the agent can do on its own and a clear answer to who governs each call that reaches a tool. Today at Build 2026, we are releasing global tool access policies as one of a set of new governance controls. This post covers how they work. Tool access policies give security and platform teams a single place to define which tools the agent can invoke, under what conditions, and what requires human approval before it runs. Underneath those policies sits the identity the agent runs as the bedrock that every other control layer depends on. It is defense in depth applied to agent behavior: layers of control, each one holding on its own, so that governing the agent is something you can read, audit, and reason about as you scale it across production. Identity is the bedrock: managed identity today, agent identity next Start here, because nothing else matters if you skip it. The identity the SRE Agent runs as, and the Azure RBAC role assignments on that identity, are the most powerful boundary the agent works inside of. If your role assignments do not grant the agent access to a resource, none of the controls below come into play, because the agent cannot reach the resource to begin with. Network rules, tool permissions, hooks, and connector contracts all sit on top of an RBAC story that you write. The features in this post add layers above that floor. They do not replace it. Today the SRE Agent operates as a managed identity, and your RBAC role assignments on that identity govern what it can do. This is the bedrock, and it is the same model your other Azure workloads already use. You assign roles, you scope them, and the agent inherits exactly what you granted and nothing more. Everything that follows assumes the bedrock is in place. With identity settled, the next question is the obvious one: where is the agent allowed to send its traffic? Permissions: govern what the agent does with a tool Identity decides what the agent can reach. Permissions decide what the agent does with the access it has, down to the individual tool. Two levels cover the range: a point-and-click grid for the common cases, and hooks when a decision needs your own code. The grid is the easy mode. Every tool the agent can use, built-in tools along with MCP servers, services, and custom tools, shows up in one searchable list with two switches. On/Off sets whether the tool is available at all; turn it off and the agent cannot use it. Allow/Ask sets what happens when it is on: Allow lets the agent run the tool automatically, Ask requires a human to approve every time, except in Autonomous mode. Select tools in bulk to flip a whole category at once, filter by category or permission, and use the Advanced permissions tab when you want rules that apply at global, per-agent, or per-thread scope instead of tool by tool. Defaults stay put until you touch them, and the engine is fail-closed: if a rule cannot be evaluated, the call is blocked rather than allowed. That covers most of what teams need. Underneath those switches are three rules, allow, ask, and deny, and the Advanced tab is where you set them by scope. Global rules apply to every agent and thread, Agent rules to one custom agent, Thread rules to a single conversation. Deny is the hard one: it blocks the tool outright no matter the run mode, and a deny at a higher scope always wins, so an Allow at thread scope cannot reopen something denied globally. That split is deliberate. A platform team sets the Global guardrails that should never be crossed and the Asks that always need a human, and service teams add their own Allow rules at Agent scope for routine work, without being able to override the guardrails above them. Platform team, Global scope: deny: bash(az * delete *) - never delete, on any agent or thread deny: bash(kubectl delete *) ask: bash(az webapp restart *) - always confirm, even in Autonomous allow: bash(az monitor *) - auto-approve monitoring queries Service team, Agent scope: allow: bash(kubectl get *) - routine read-only work allow: bash(kubectl describe *) Two details make this safe to lean on. Rules match the canonicalized tool invocation rather than the raw text, so enforcement holds no matter how the command was assembled. And fail-closed has a softer edge than a hard stop: a cached last-known-good policy covers transient failures, so a blip in the policy store blocks the call rather than silently widening access. You can find these under Capabilities > Tools missions. The layer worth spending time on is hooks. Allow and Ask answer "should this tool run." Hooks answer "should this specific call run, given exactly what it is about to do." A hook fires before the agent runs a tool and receives the actual call, parameters and all. Your code then decides the outcome and can reshape it: rewrite parameters before they are sent, inject extra context into the pipeline as a user message so the agent reconsiders before its next step, block the call outright, or redirect the agent toward a safer path. Because your code sees the real parameters, the decision can depend on anything you can express in code: which resource the call targets, whether a value falls outside an allowed range, the time of day, the result of an external policy lookup. This is where you write the rule the grid cannot. Two kinds of hook, mixable on the same agent. Command hooks are a script you write; reach for these when code is enough. Prompt hooks put a separate LLM in the loop as a judge that evaluates the call in context; reach for these when the decision needs reasoning rather than a fixed rule. A real example from our own internal test agent: when the agent tries to list files through the shell with ls or dir, a hook blocks the call. The agent absorbs the signal, reconsiders, and reaches for the ListDir tool instead. The hook did not argue with a human. It shaped what happened next. As with the grid, configure nothing and the agent behaves exactly as it does today. Both are additive. Authoring one is a short form. You name the hook, pick the event (Pre Tool Use, so it runs before the call), and set a tool matcher, either picked from the tool menu or written as a regex like (FetchWebpage|SearchMemory) with anchors and lookaheads when you need them, so the hook fires only on the calls you care about. You set a timeout and a fail mode (Block, so a hook that errors or hangs stops the call rather than waving it through), and you write the body in Bash or Python. A command hook reads the call as JSON on stdin, the event name, the tool name, its parameters, and the call id, and answers on stdout. Print nothing and exit zero to allow. Return a block decision with a reason to stop the call, and that reason is what the agent reads back. You can also substitute: run a cheaper or safer version yourself, block the real call, and hand your own output back as the result, so the agent never runs the expensive or risky original. #!/bin/bash input=$(cat) tool=$(echo "$input" | jq -r '.tool_name') # Block one tool, with a reason the agent will read if [ "$tool" = "ExampleToolName" ]; then echo '{"decision":"block","reason":"Blocked ExampleToolName by hook policy."}' exit 0 fi # Otherwise allow: print nothing and exit 0 exit 0 You can find these under Builder > Hooks Each layer holds on its own The layers stack. Identity is the floor: your RBAC assignments decide what the agent can reach at all. Permissions, the grid and hooks together, decide what it does with a tool. You author each layer, each one holds whether or not the layer above it behaves as expected, and all of it configures through the same ARM and Bicep surface your platform team already uses, reproducible the way the rest of your Azure estate is. The upgrade path is additive and non-breaking. Existing agents keep working. Turn on each control when you are ready, in the order your governance requires. There is more coming. We run Azure SRE Agent inside Microsoft on our own production workloads, so we feel the same gaps you do, and the next round is shaped by what we hear from teams running it in production today. Which control is doing the most for you, and which one are you still waiting on? Let us know and thank you! Getting started Create new SRE Agent — https://aka.ms/sreagent SRE Agent Documentation — https://aka.ms/sreagent/newdocs SRE Agent recipes — https://aka.ms/sreagent/recipes Build 2026 Announcement - https://aka.ms/Build26/blog/SREAgentLogic Apps Aviators Newsletter - June 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month June 2026's Ace Aviator: Florian De Langhe LinkedIn: https://www.linkedin.com/in/floriandelanghe/ What's your role and title? What are your responsibilities? Lead Expert/Team Lead for the Microsoft Integration team at delaware. I have a wide range of responsibilities: - People management - Resource planning - Design and operate our integration solutions at our customers, what we brand as "SmartLink". Next to this, as many of us, I follow the latest AI news closely to keep up to date and try to stay ahead of the curve. Can you give us some insights into your day-to-day activities? I wear many hats so no two days look the same. That is also what keeps it interesting. A typical day starts with reviewing resource planning across our active projects, followed by a technical design review for a new integration. Sprinkle some one-on-one coaching conversations and research into new technologies/features and you have my day. The balance between People leadership and hands-on technical work is what I enjoy most. What motivates and inspires you to be an active member of the Aviators/Microsoft community? I started out being an active member on the Microsoft Logic App forum 10 years ago. I remember going back and forth with Wagner through the forum posts trying to solve questions. Good times. Integration is one of those disciplines where you're constantly connecting systems, teams, and ideas. What motivates me is seeing how members of our community across different companies and countries solve similar problems in completely different ways. The Aviators community has that right mix of deep technical knowledge and willingness to help each other out. Since discovering Integration and the Microsoft community, I basically never left. Looking back, what advice do you wish you had been given earlier? Document everything and treat documentation as a deliverable, not an afterthought. Early in my career I saw documentation as the boring part that you do after the development work. Now I see it as the leverage point. A well-written design document doesn't just help the next person understand what you built, it compounds. It feeds code generation, easier onboarding of new members and validation with your customers on what and how to build it. What has helped you grow professionally? Two things: 1) Always challenge yourself and your implementations; everything can be better, so I am always pushing myself to keep learning, stay up to date, and think about every idea/solution posted in this community—how it could improve my way of thinking or solutions that I am building/have built. 2) Focus on understanding the integration concepts and patterns. At the end of the day everything is a pattern; it is how you implement where we make the difference. So knowing the base layer itself helps a lot when building integration solutions. If you had a magic wand that could create a feature in Logic Apps, what would it be? To be able to control scaling of the workflow service plans more fine grained. Being able to control this would unlock a lot of use cases, especially for the combination of Logic Apps and Service Bus concurrency and throughput. News from our product group Write Logic Apps in C#: introducing the Logic Apps Standard SDK This article introduces the Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk), a code-first way to define Logic Apps Standard workflows in C#. Developers compose workflows using a fluent builder with strongly typed triggers and actions, including both built-in and managed connector operations. The SDK preserves the existing runtime, connectors, monitoring, and run history while changing only the authoring experience. It supports control flow constructs, custom C# code steps, and run-after conditions for fault handling. Guidance covers getting started in VS Code, project layout, local F5 execution, and preview limitations such as no service provider connectors and work-in-progress managed identity support. New AI gateway capabilities in Azure API Management Azure API Management expands its AI gateway with a Unified Model API (preview) that lets clients use a single OpenAI-style format across providers, plus model aliases and discovery. GA updates include support for Anthropic and Google Vertex AI and content safety for MCP and Agent-to-Agent (A2A) traffic. Token observability now tracks cached, reasoning, and thinking tokens in Application Insights. Foundry import adds Anthropic API operations. A2A APIs reach GA with richer diagnostics and availability in classic tiers. Together, these features standardize governance, security, and observability for multi-model, multi-protocol AI applications. 🎉 Automation just became a team sport. Meet Azure Logic Apps Automation. Azure Logic Apps Automation (public preview) is a new SKU that delivers a managed, SaaS-like experience for building and running workflow automations. It keeps the enterprise-grade Logic Apps engine while simplifying onboarding, collaboration, and governance with projects and applications, flexible permissions, and policy inheritance. The experience is AI-native with natural language authoring, first-class agents, tools via MCP, and managed sandboxes. It introduces a modern designer, draft mode, live run history, JavaScript expressions, elastic scale to zero, and knowledge-as-a-service integration—aimed at helping teams prototype quickly and operate securely at scale. 📢 Announcing Knowledge as a Service for Azure Logic Apps Knowledge as a Service (public preview) provides a managed knowledge layer for Logic Apps that turns documents into a ready-to-use knowledge base without building a custom RAG pipeline. The service handles ingestion (parsing, chunking, embeddings) and retrieval (query rewriting, semantic search, ranking) and integrates with agentic workflows in Logic Apps Standard and the Automation SKU. On Standard, teams bring their own vector store and models; on Automation, the platform hosts them on behalf of the user. It supports Entra authentication and focuses on secure, grounded responses for agents and workflows. Better Together: Build Agents in Microsoft Foundry, Automate them with Azure Logic Apps This post outlines a combined stack for agentic applications: Microsoft Foundry for building and hosting agents, and Azure Logic Apps for invoking and orchestrating them. New capabilities let teams create or select Foundry agents directly from the Logic Apps designer, pair any trigger with an agent for autonomous execution, and expose 1,400+ Logic Apps connectors and entire workflows as agent tools. The approach enables agents to act across systems, handle long-running processes, and integrate with enterprise events, making deterministic workflows and AI-driven reasoning work together in production. What's new in Azure API Management at Microsoft Build 2026 This roundup covers Build 2026 updates for API Management and API Center: GA for agent registration, assessment, and Git sync in API Center, plus a data plane MCP server for enterprise discovery. API Management adds GA support for JSON‑RPC agent‑to‑agent (A2A) APIs and extends content safety controls to MCP and A2A flows. Unified Model API enters preview to standardize client integration across model providers, and AI Gateway expands to Anthropic and Vertex AI with broader token metrics. Platform enhancements include multi‑domain and wildcard custom hostnames in v2 tiers and workspace support on the built‑in gateway. Azure Connector Namespaces: managed integration for any Azure compute Azure Connector Namespace (preview) offers a fully managed integration layer that brings the Logic Apps connector ecosystem to any Azure or self‑hosted compute without requiring a workflow engine. Apps call strongly typed SDKs for C#, Node.js, or Python to invoke actions and subscribe to triggers, while the namespace handles auth, token rotation, retries, throttling, and webhook delivery. It also projects connectors as MCP servers for agents, and supports hosted MCP servers like Playwright and Azure SQL. The post details building blocks, scenarios, security, governance, and preview limitations. What's new in Azure Logic Apps at Microsoft Build 2026 This Build 2026 overview highlights Logic Apps Automation (public preview), GA for the Logic Apps MCP Server to expose workflows as MCP tools, direct invocation of Microsoft Foundry agents from Logic Apps, Knowledge as a Service, and code‑first development with the Logic Apps Standard SDK (Codeful Workflows). It also introduces a Migration Agent to help modernize from legacy platforms. The theme is making enterprise‑grade automation more accessible while preserving governance, reliability, and operational controls for production use. Hosted MCP Servers in Connector Namespace (Preview) Hosted MCP servers in Connector Namespace let teams deploy managed, enterprise‑ready MCP servers from a curated catalog in minutes. The platform handles deployment, scaling, authentication (inbound with Entra ID, outbound with managed identity or on‑behalf‑of), availability, and observability via Application Insights. Preview servers include Playwright for browser automation and Azure SQL via Data API Builder, enabling agents to use reliable tools without the overhead of self‑hosting. The post explains setup, benefits over self‑hosted servers, and areas of ongoing investment like catalog expansion and VNet support. MCP Test Console and Git Repository synch in Azure API Center Azure API Center adds a built‑in MCP Test Console in the developer portal and Git repository synchronization for MCP servers and other assets. Developers can validate MCP tools interactively on the Documentation tab and browse server tiles with endpoints and schemas. Git sync keeps the API Center inventory aligned with source‑controlled definitions, with secure access via Key Vault and managed identity. Together, these additions streamline discovery, testing, and governance of MCP assets across the enterprise. Bringing all your Integration workloads to Logic Apps Standard This post outlines Microsoft’s guided path for moving enterprise integration workloads—especially BizTalk—to Azure Logic Apps Standard. It introduces the open-source Logic Apps Migration Agent, which delivers an AI‑assisted, stage‑gated process across discovery, planning, baseline conversion, and continuous validation with human‑in‑the‑loop checkpoints. The workflow integrates with VS Code and GitHub Copilot, supports incremental “flow‑group” migration, and accommodates existing black‑box tests. The article also previews mission‑critical capabilities arriving for Standard and Hybrid (HL7, MLLP, Rules Engine, MSMQ, Oracle DB, flat‑file generation, Integration Accounts, and more), giving teams a repeatable, auditable modernization path with reduced risk. Announcing Microsoft Host Integration Server 2028: Modern connectivity for IBM Mainframes Midranges Host Integration Server 2028 (HIS 2028) is the next HIS release, delivered as a standalone SKU decoupled from BizTalk. It modernizes platform foundations (.NET 10) and, for non‑SNA features, introduces Linux support. New investments include Foundry integration for agent scenarios, REST APIs for DB2 and Transaction Integrator workloads, Entra ID and Azure Arc for hybrid management, a move to Visual Studio Code for designers, and alignment with newer IBM middleware. The post also lists product cleanup and deprecations (e.g., 32‑bit, WMI/WCF, BizTalk adapters), helping enterprises secure, govern, and operate host connectivity for years ahead. Easy Auth Configuration for Logic App Standard through CI/CD Enabling App Service Easy Auth on Logic Apps Standard can break run‑history views because SAS‑based runtime calls are blocked before the Logic Apps engine can validate them. This article explains two remedies: allow unauthenticated requests (so the runtime enforces its own auth), or keep Easy Auth strict and exclude runtime endpoints (e.g., /runtime/*) using authsettingsV2. It provides CI/CD‑ready approaches via ARM/Bicep templates or a post‑deployment REST API call, and highlights key settings such as requireAuthentication, unauthenticatedClientAction, excludedPaths, and allowedApplications. The guidance restores run‑history usability while maintaining enterprise authentication policies. Run Javascript code on Agent Loop Azure Logic Apps Agent Loop now supports a JavaScript code interpreter, extending earlier code‑execution support and enabling reliable computations, validations, and transformations alongside LLMs. The runtime executes generated or pre‑written code inside a V8 isolate using the isolated‑vm library, providing memory limits, timeouts, and failure isolation (not a full sandbox) to reduce blast radius. A worked example shows expense‑validation with agent tools orchestrated in a workflow. For Consumption, attaching an Integration Account provides isolated compute for the interpreter. The capability helps teams combine deterministic steps with agentic reasoning to deliver robust, auditable outcomes. Bulk-configure diagnostic settings on Azure Logic Apps Consumptions LA‑BulkDiag is a single‑file PowerShell script that bulk‑applies diagnostic settings across Logic Apps Consumption in a resource group. It inventories workflows, supports quick scopes (bare/all/pick), verifies destinations, auto‑renames on name collisions, and ships with 129 Pester tests. Presets cover logs, metrics, and workflow‑runtime categories; selection grammar enables non‑interactive runs suitable for CI. The post includes quick‑start commands and clarifies scope: it targets Consumption only (not Standard) and doesn’t configure Event Hub sinks. The result is faster, consistent observability at scale without repetitive portal clicks or accidental overwrites. Clean up idle and always-failing Azure Logic App Consumption LA‑CleanUp is a PowerShell utility that scans a subscription for Logic Apps Consumption workflows, classifying them as Idle (no runs in N days) or AlwaysFailing (runs in the window with zero successes). It can export candidates to CSV, then guide per‑item deletion with y/N/q prompts, reporting final counts. Under the hood, it uses OData filters and $top=1 queries for fast server‑side checks, caches an ARM token once, and intentionally avoids cross‑subscription operations. Scope notes: it doesn’t touch Standard workflows or API connections. The tool reduces noise, costs, and operational drag from abandoned or broken apps. News from our community Spec2Integration Post by Balbir Singh Spec2Integration proposes a spec-driven approach to building Azure Integration Services solutions. The open-source toolkit guides teams from a product brief through specification, modeling, contracts, mapping, and architecture to a deployable implementation targeting Azure Logic Apps, Functions, and related services. It includes governance gates for idempotency, observability, retries, and PII handling, plus a VS Code extension that visualizes pipeline status and the integration representation. Templates and tooling support greenfield projects and BizTalk migrations. The result aims to standardize repeatable steps, reduce failure modes, and accelerate delivery while keeping architectural control outside individual workflows. Stateful Orchestration in Azure: When Logic Apps Break, and What to Do Instead Post by Al Ghoniem, MBA This article examines where stateful orchestration with Azure Logic Apps can fall short and how to design around those gaps. It differentiates execution state from business state and highlights common failure modes: long-running instances, retry-induced duplicates, partial completion across SAP/Oracle/APIs, lost correlation, and unowned DLQs. It then contrasts orchestration choices—stateful Logic Apps, Durable Functions, Service Bus–backed orchestration, and choreography—emphasizing idempotency, correlation, reconciliation, and compensation. The guidance steers architects toward a control and observability layer so production incidents can be traced, replayed, and recovered without relying on workflow run history alone. Logic Apps Announcements at Microsoft Build Video by Sebastian Meyer This video recaps Logic Apps announcements from Microsoft Build with insights from a member of the product team. It highlights newly introduced capabilities and shares resources for deeper dives. Viewers get a concise overview of what’s new, why it matters for integration practitioners, and where to learn more. The discussion points architects toward practical use cases and next steps, making it a useful primer for anyone assessing roadmap impacts on existing or upcoming Azure Integration Services projects. Logic Apps Standard vs. Consumption: Which Plan Should You Choose? Post by Chiranjib Ghatak The article compares Logic Apps Standard and Consumption, explaining differences in hosting models, pricing, networking, and development experience. It outlines when to pick each plan, noting Standard’s single-tenant model, VNet/private endpoints, built-in connectors, and local DevOps workflow, versus Consumption’s pay-per-execution model and simplicity for sporadic or low-volume workloads. It also covers performance trade-offs, stateful vs. stateless options available in Standard, and typical enterprise scenarios where Standard provides predictable costs and better throughput. Azure Connector Namespaces: Managed Connectors Beyond Logic Apps Post by Şahin Özdemir This post introduces Azure Connector Namespaces and previews managed connectors for Azure Functions, extending the Logic Apps connector ecosystem to more compute services. It explains the motivation, how namespaces decouple connectors from workflows, and the benefits: reduced custom code, consistent authentication via managed identity, and reuse of Microsoft-managed integrations. A step-by-step walkthrough shows creating a namespace, adding a managed connector, and using the Azure Connectors .NET SDK in Functions, illustrating how teams can standardize connectivity while keeping business logic in code. Stop working harder and start flowing smarter, with Logic Apps Automation Post by Sonny Gillissen Sonny Gillissen explores Logic Apps Automation, a new, governed experience for building enterprise automations. He explains the Project → Application → Workflow model, dedicated portal (auto.azure.com), and reusable Sandboxes for agent code. The post shows how the AI assistant can scaffold workflows from intent, with Knowledge sources to ground agents, while monitoring and analytics provide visibility. Benefits include familiar Logic Apps design, reduced operational overhead, and scale-to-zero. Current gaps are noted—OBO auth shift, occasional assistant syntax issues, managed vs. built‑in connector choices, no migration tooling yet, and pending VNet/private endpoint support. Stop Using Static Filters! Automate DIXF Exports with Logic App Post by Anitha Eswaran Anitha Eswaran demonstrates how to make DIXF exports in D365FO dynamic using Azure Logic Apps and a small X++ customization. A custom OData action updates the DIXF Definition Group filter at runtime based on a parameter such as Customer Group. A Logic App triggered by a business event parses the input, stores the value, calls the OData action, invokes the standard ExportToPackage API, and then retrieves the download URL via GetExportedPackageUrl to fetch the ZIP with a time‑limited SAS token. Screenshots and code samples illustrate the end‑to‑end flow and implementation details. Logic Apps Agent Loops: Master Class Video by Stephen W Thomas Stephen W Thomas compiles his full Logic Apps Agent Loop series into one master‑class video. It covers getting started with Agent Loop on Logic Apps Standard, a human‑in‑the‑loop pattern used to resolve failed code translations, interactive chat agents with secure website embedding via Easy Auth, and when to choose the Consumption tier for simpler, pay‑as‑you‑go deployments. The chaptered format lets viewers jump to relevant topics. The emphasis is on the orchestration pattern—agents that select and compose tools to achieve goals—offering a practical foundation for teams moving from deterministic workflows toward agentic automation. Forget Sampling — This One host.json Setting Cuts Logic Apps Telemetry Costs by 80% Post by Daniel Jonathan This article tackles high Application Insights ingestion costs in Logic Apps Standard and shows a data‑driven path to reduce spend. Through a controlled experiment, it demonstrates that switching Runtime.ApplicationInsightTelemetryVersion to v2 in host.json delivers ~80% reduction without sacrificing troubleshooting. Further options include disabling dependency tracking (eliminates AppDependencies with the trade‑off of losing per‑call HTTP detail) and using adaptive sampling for marginal additional savings, while excluding exceptions. It also explains why some run‑level telemetry bypasses sampling and how to toggle sampling via an environment variable for short‑term diagnostics. Production Is the Only Truth in Integration Post by Marcelo Gomes This piece reframes integration success through a production‑first lens. It argues that reliability emerges when systems are designed for failure as the norm, not the exception. The article urges separating orchestration from business logic—using tools like Azure Logic Apps for coordination and Azure Functions for rules and transformations—to keep retries safe and evolution predictable. It positions production‑readiness as a design concern, emphasizing idempotency, replay, observability, runbooks, and ownership. The practical outcome is reduced operational risk and cost, more predictable behavior, and greater business trust in automated processes. DevUP Talks #05 – Logic Apps Tips & Tricks with Sandro Pereira Video by Mattias Lögdberg In this session, Sandro Pereira distills practical guidance from real projects to help teams build more resilient Logic Apps. Topics include applying environment‑specific timer conditions, deploying Logic Apps in a disabled state to control activation during releases, and using User‑Managed Identity with Azure Service Bus in Logic Apps Standard. The video focuses on patterns that improve reliability, security, and operational control across environments, offering actionable advice for developers and architects working in Azure Integration Services who want fewer surprises in production and a smoother deployment lifecycle. Logic Apps: Service Bus with User‑Assigned Managed Identity Post by Sandro Pereira This best‑practices guide shows how to configure the Azure Service Bus connector in Logic Apps Standard to use a user‑assigned managed identity. Sandro Pereira explains why system‑assigned identities complicate CI/CD—RBAC can’t be fully declared until the identity exists—then demonstrates a pattern that keeps deployments reproducible. The approach uses app settings for the Service Bus namespace and identity resource ID, a custom serviceProviderConnections entry referencing those settings, and workflow actions bound to that connection. The result is secretless, declarative authentication that avoids RBAC timing issues across environments. Logic App Consumption Bulk Failed Runs Resubmit Tool Post by Sandro Pereira Sandro Pereira introduces a small .NET Windows utility that lists and bulk resubmits failed Logic Apps Consumption runs. After authenticating to Azure, users supply the Logic App name, resource group and subscription. The tool can optionally filter by a date range, otherwise it returns up to 250 failed runs for fast triage. It targets a common pain point the portal features don’t fully streamline and includes a link to the GitHub source so teams can adapt or integrate it into operational workflows. A concise “one‑minute brief” outlines the problem and practical benefits. Control the Initial State of Logic Apps Standard Workflows Post by Sandro Pereira This tip explains how to prevent Logic Apps Standard workflows from starting immediately after deployment—a common production risk. Instead of a state property in ARM/Bicep, the initial state is controlled via App Settings on the underlying App Service. By setting Workflows..FlowState to Disabled (in local.settings.json and/or app settings), teams ensure workflows deploy in a safe, non‑running state. The article outlines the rationale, differences from Consumption, and provides concrete examples and screenshots to adopt the practice across environments.
