Azure Integration Services Blog articles

🆕Orchestrate Foundry Prompt and Hosted Agents with Logic Apps Automation

DivSwa — Wed, 21 Oct 2026 00:45:18 GMT

Microsoft Foundry is retiring workflows on December 1, 2026. After that date, the visual workflow designer and running workflows in the Foundry portal won’t be supported.

For business process automation that combines deterministic steps with AI reasoning, the Foundry migration guide recommends Azure Logic Apps. Logic Apps is especially well suited to building these processes visually: Foundry agents become steps in a workflow, running alongside built-in actions, APIs, and MCP servers in the same run.

Beyond the migration, there’s a broader question many teams face once an agent is working. Most agents start out as interactive, chat-based experiences: a person asks, and the agent responds. Putting that same agent to work in a business process means it has to run autonomously, started by an API call or an event instead of a person, running in the background and at scale. It also has to fit alongside the deterministic steps the process already depends on, such as gathering data before the agent runs and validating and acting on its output afterward.

With support for Foundry Prompt Agents and Foundry Hosted Agents, Azure Logic Apps Automation gives you a direct way to do this. Any agent you’ve built in Foundry can become a step in a workflow. It can be started by an API call, a schedule, or an event from one of 1,400+ connectors, run in the background at scale, and sit between the deterministic steps that come before and after it.

Before we get to the workflow side, here’s a quick look at the two agent types. If you want the full picture, the Foundry Agent Service overview compares them in detail.

What are Foundry Prompt Agents

A Prompt Agent is an agent you configure rather than code. You write instructions, pick a model, attach tools, and Foundry runs it. There’s nothing to deploy and no scaling to think about.

It can use the Foundry model and tool catalogs, including knowledge sources like Azure AI Search and Foundry IQ. You pay for the tokens and tool calls it uses, with no separate platform charge.

If you can write down what the agent should do and which tools it needs, a Prompt Agent will usually do the job, and it’s the quickest way to get something working. The prompt agent quickstart walks through building one.

What are Foundry Hosted Agents

A Hosted Agent is your own agent code, packaged as a container and run on Microsoft Foundry Agent Service. You can build it with Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, or your own code. Foundry handles the hosting and scaling.

Since it’s your code, you decide how the agent loop works. Each session gets its own isolated sandbox with the CPU and memory you choose, and files and state persist between turns. Each Hosted Agent also gets its own Microsoft Entra agent identity, so you can see and audit what it does like any other identity in your tenant.

Hosted Agents use the same models and tools as Prompt Agents. On top of tokens and tool calls, you pay for the compute they use (vCPU and memory hours). You can read more about how Hosted Agents work.

A simple way to choose: start with a Prompt Agent. Move to a Hosted Agent when you need custom code or custom orchestration or want to bring your own code and framework.

Orchestrate Foundry agents with Logic Apps workflows

An agent in Foundry runs when someone or something calls it. Most business processes start somewhere else: an email comes in, a ticket is opened, a file lands in SharePoint, or a schedule fires. They usually end somewhere else too, with a record updated or someone getting a message.

Logic Apps covers both ends and everything in between: a trigger to start the agent, deterministic steps around it, and branching, retries, timeouts, and parallel branches for the agent call. The next two sections show what that looks like.

Every run shows up in run history, with the inputs, what the agent returned, and what happened next. When something goes wrong, you can see exactly where. The Learn article on automating Foundry agents with workflows covers the setup step by step.

Run agents autonomously from any trigger

The simplest setup is a trigger, an agent, and an action. Say a support email arrives in Outlook. The workflow sends it to a Prompt Agent that classifies it and drafts a reply, then creates a ticket with the result. This runs every time an email arrives, with no one starting it.

Schedules work the same way. A recurrence trigger could call a Hosted Agent every Monday to go through last week’s data and post a summary in Teams.

Mix agentic reasoning with deterministic steps

Most processes are largely rule-based, with a step or two that needs adaptive reasoning or a decision. In Logic Apps you use an agent for those steps and keep everything else as deterministic steps.

Before the agent runs, collect what it needs. Look up the customer in your CRM, pull the contract from SharePoint, or query a database, and pass all of it in.

After it runs, check what came back. Validate it against a schema, apply your business rules, and send anything uncertain to a person for approval. Then write the result to the right system with a connector.

Use both agent types in one workflow

You don’t have to pick one type of agent per process. A workflow can call a Prompt Agent for a quick classification and send only the harder cases to a Hosted Agent for a longer analysis.

The workflow passes output from one agent to the next, runs agents in parallel when they don’t depend on each other, and brings the results back together. Each agent stays small, and the end-to-end logic lives in the workflow, where you can see it and change it.

How to use Foundry Agents from Workflows

Hosted Agent

You can create Foundry Hosted Agents directly from your Logic Apps Automation application. Pick your Foundry project and model deployment, and the app takes care of identity, permissions, and readiness checks for you. In a workflow, the Foundry Hosted agent action sends the agent its instructions, task, files, and any workflow actions you’ve added as tools. It returns the agent’s final response and generated files for the next steps to use.

For details, see Foundry Hosted Agents for an overview and Create and use a Foundry Hosted Agent for step-by-step setup.

https://youtu.be/foN9oPu5lRE

Prompt Agent

You can call an existing Foundry Prompt Agent from a workflow or create a new one right from the designer . Connect to your Foundry project, then either pick an agent from the list or select Create new agent and give it a name, a model, and instructions. The agent is created and hosted in Foundry.

You can also give the agent tools from Logic Apps: actions from 1,400+ connectors, built-in actions, APIs, MCP servers, and other workflows.

https://youtu.be/YkM7dHzHjdM

Roadmap

Today, workflows can invoke Hosted Agents that you create from your Logic Apps Automation app. We’re adding support for selecting an existing Hosted Agent from your Foundry project and invoking it from a workflow.

Get Started

Read to automate! Start building at auto.azure.com
Automation QuickStart
Automation Documentation - https://auto.azure.com/docs/

Deploying Logic Apps Hybrid through an Azure DevOps pipeline

anandgmenon — Mon, 19 Oct 2026 05:16:43 GMT

Overview

Logic Apps Hybrid runs Standard workflows on your own infrastructure: an Arc-enabled Kubernetes cluster that appears in Azure as a connected environment. You still author and manage the workflows in Azure, but the runtime is yours.

Until now, setting up CI/CD for this meant writing the ARM template and the pipeline YAML by hand, and working out a few Hybrid-specific details along the way.

The Azure Logic Apps (Standard) extension for Visual Studio Code can now generate all of it for you: the infrastructure template, its parameter file, and both pipelines. A separate Azure DevOps extension supplies the pipeline tasks that do the Hybrid-specific work.

This post covers the whole path: generating the assets, what is inside them, the service connections and variables you need to supply, and running both pipelines.

Things to consider first

Three things work differently in Hybrid than in a cloud-only Standard deployment. The generated assets handle all of them, but the pipelines are much easier to follow once you know what they are.

Connections cannot use managed identity

Infrastructure as code for Standard normally produces managed API connections that authenticate with ManagedServiceIdentity. That does not work in Hybrid, because the runtime executes inside a container on your own cluster where no Azure managed identity is available.

Hybrid connections use ActiveDirectoryOAuth with a Microsoft Entra ID app registration instead. The Hybrid Build task rewrites this at build time, so you do not have to. Any *-Authentication parameter of type ManagedServiceIdentity becomes:

{
  "type": "ActiveDirectoryOAuth",
  "tenant": "@appsetting('WORKFLOWAPP_AAD_TENANTID')",
  "clientId": "@appsetting('WORKFLOWAPP_AAD_CLIENTID')",
  "secret": "@appsetting('WORKFLOWAPP_AAD_CLIENTSECRET')",
  "audience": "https://management.core.windows.net/"
}

The @appsetting() references resolve at runtime against Container App environment variables that the infrastructure template sets. The same package can therefore go to any environment; only the app settings change.

The runtime runs on your cluster

A Hybrid logic app uses Azure Container Apps on Arc-enabled Kubernetes. It is deployed as a Microsoft.App/containerApps resource with kind: workflowapp, tied to your cluster through a custom location. Workflow content lives on an SMB file share mounted at /home/site/wwwroot.

Deployment goes through a ZIP deploy endpoint

There is no App Service publishing involved. The package is posted to the Hybrid logic app's zipdeploy endpoint, authorized with a bearer token from the client credentials flow. That is why the release task needs its own Hybrid Logic App service connection holding the Entra ID tenant, client ID, and client secret.

What you'll build

A CI pipeline that packages your workflows and publishes the application ZIP and infrastructure templates, and a CD pipeline that deploys the infrastructure and releases the package to your Hybrid logic app. The runtime runs on your Arc-enabled Kubernetes cluster, with SQL for workflow state and an SMB share for application content.

Prerequisites

This post assumes the Hybrid environment already exists. If you have not set one up yet, follow the official guide to set up your infrastructure for Standard logic app workflows with hybrid deployment.

For an automated AKS-based evaluation environment, you can also use the Azure Arc Jumpstart template, Hybrid deployment for Azure Logic Apps on AKS. Use it for evaluation and validation, not as a production reference architecture.

On the Azure side you need:

An Arc-enabled Kubernetes cluster with a connected environment (Microsoft.App/connectedEnvironments) and a custom location
An SMB file share the cluster can reach: host name, share path, user name, and password
A SQL Server connection string for the Hybrid runtime state store
A Microsoft Entra ID app registration, along with its client ID, object ID, tenant ID, and a client secret

On the tooling side:

Visual Studio Code with the Azure Logic Apps (Standard) extension, version 3.3.0 or later
An Azure DevOps project with a Git repository
The Azure Logic Apps Standard Tasks extension installed in your Azure DevOps organization. This extension includes the Hybrid build and release tasks.

Install the Azure DevOps extension before you create the pipelines. It provides the pipeline tasks used below as well as the Hybrid Logic App service connection type, and without it the YAML fails validation with an unknown task error.

Step 1 — Generate the deployment scripts from VS Code

Open your Logic App Standard project in VS Code and work through the wizard:

Right-click the project in the Explorer, or open the Command Palette, and choose Generate deployment scripts.
For the deployment script type, select Azure DevOps Pipeline.
For the deployment target, select Hybrid (Container Apps).
Select the subscription and resource group to deploy into.
Select the connected environment that hosts your Hybrid runtime.
Enter the name for the Hybrid logic app to create in Azure.

Launch the wizard from the project context menu in the Explorer.

Choose Hybrid (Container Apps) as the deployment target.

Only environments in the same region as the selected resource group are listed.

A couple of things happen for you here. The connected environment list only shows environments in the same region as the resource group you picked, so you cannot end up with a cross-region mismatch. The environment's resource group is read from its resource ID rather than typed in, which helps because the connected environment often sits in a different resource group from the logic app.

Step 2 — Review what was generated

The wizard creates a deployment folder in your workspace:

deployment/
└── <logic-app-name>/
    ├── infrastructure/
    │   ├── hybrid-logicapp-template.json
    │   └── hybrid-logicapp-parameters.json
    ├── pipelines/
    │   ├── CI-pipeline.yml
    │   ├── CI-pipeline-variables.yml
    │   ├── CD-pipeline.yml
    │   └── CD-pipeline-variables.yml
    └── workflowparameters/
        └── parameters.json

The generated deployment folder, added to your workspace.

The infrastructure template

hybrid-logicapp-template.json deploys:

Resource	Purpose
`Microsoft.App/connectedEnvironments/storages`	Registers the SMB file share with the connected environment
`Microsoft.App/containerApps` (`kind: workflowapp`)	The Hybrid logic app, pinned to your custom location, with the file share mounted at `/home/site/wwwroot`

It also creates the secrets and app settings the runtime needs, among them:

Workflows.Sql.ConnectionString for the runtime state store
WORKFLOWAPP_AAD_TENANTID, WORKFLOWAPP_AAD_CLIENTID, WORKFLOWAPP_AAD_CLIENTSECRET and WORKFLOWAPP_AAD_OBJECTID, which the rewritten connection authentication resolves against
APP_KIND, FUNCTIONS_EXTENSION_VERSION and IS_ZIP_DEPLOY_ENABLED for runtime configuration

The sensitive values (sqlConnectionString, fileSharePassword, aadClientSecret) are declared as securestring and passed in by the pipeline at deployment time, so nothing sensitive is committed to the repository.

The CI pipeline

jobs:
- job: logic_app_build
  displayName: 'Build and publish Hybrid Logic App'
  steps:
  - task: AzureLogicAppsHybridBuild@0
    displayName: 'Azure Logic Apps Hybrid Build'
    inputs:
      sourceFolder: '$(Build.SourcesDirectory)/$(sourceFolderName)'
      deploymentFolder: '$(System.DefaultWorkingDirectory)/deployment/$(logicAppName)/'
      archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'

  - task: PublishPipelineArtifact@1
    displayName: 'Publish logic app zip artifact'
    ...
  - task: PublishPipelineArtifact@1
    displayName: 'Publish infrastructure artifacts'
    ...

The Hybrid Build task copies the project, skipping local-only files such as local.settings.json, applies the authentication rewrite described above, and produces the deployment ZIP. It publishes the application package and the infrastructure templates as separate artifacts, so CD deploys exactly what CI built.

The CD pipeline

- task: AzureResourceManagerTemplateDeployment@3
  displayName: 'Deploy Hybrid Logic App Infrastructure'
  ...
- task: AzureLogicAppsHybridRelease@0
  displayName: 'Azure Logic Apps Hybrid Release'
  ...

Task	What it does
`AzureResourceManagerTemplateDeployment@3`	Deploys the Hybrid logic app and registers its file share, injecting the three secrets as override parameters
`AzureLogicAppsHybridRelease@0`	Resolves the Hybrid logic app's deployment endpoint, applies runtime settings, acquires an Entra ID token, and deploys the ZIP package

Known limitation. The generated CD pipeline also contains a Deploy Managed Connections step, gated by a deployConnections variable. Deploying managed API connections for Hybrid is not supported yet, so leave deployConnections set to false. Create any managed connections your workflows need separately for now.

Step 3 — Commit and push

Commit the generated deployment folder together with your logic app project and push to your Azure DevOps repository. Both pipelines read their templates and variables from the repo.

Step 4 — Create the service connections

Hybrid deployment uses two service connections. Both are created under Project settings > Service connections.

Azure Resource Manager. Used to deploy the infrastructure and to read and update the Hybrid logic app's configuration. Select your subscription and give it a name, for example azureServiceConnection.

Hybrid Logic App. Used to authenticate against the ZIP deploy endpoint. This connection type comes from the Azure DevOps extension. Supply the Entra ID tenant ID, the app registration's client ID, and its client secret, then name it, for example hybridServiceConnection.

The Hybrid Logic App service connection type comes from the Azure DevOps extension.

Step 5 — Fill in variables and secrets

The generated variable files contain placeholders. Replace them with your own values.

pipelines/CI-pipeline-variables.yml

variables:
  logicAppName: 'my-hybrid-logicapp'
  # Folder in the repo that contains the Logic App project (host.json, workflows).
  # This is the local project name, which can differ from the deployed Logic App name above.
  sourceFolderName: 'my-project-folder'
  logicAppCIArtifactName: 'logic-app-artifact'

sourceFolderName is the folder in your repository that contains host.json and your workflows. logicAppName is the name of the deployed Hybrid logic app, and it also decides the deployment/<logicAppName>/ folder path. The two are often different, which is why they are separate variables.

pipelines/CD-pipeline-variables.yml

variables:
  azureServiceConnection: '<your-azure-service-connection>'
  hybridServiceConnection: '<your-hybrid-service-connection>'
  subscriptionId: '<your-subscription-id>'
  containerAppName: 'my-hybrid-logicapp'
  resourceGroupName: '<your-resource-group>'
  location: '<your-location>'
  logicAppCIArtifactName: 'logic-app-artifact'
  logicAppEnvironment: 'production'
  deployConnections: 'false'

Set deployConnections to false, as noted in the limitation above.

Do not put the secrets in YAML. Add them as secret pipeline variables on the CD pipeline, under Edit > Variables, with Keep this value secret selected:

Secret variable	Used for
`sqlConnectionString`	Hybrid runtime state store
`fileSharePassword`	SMB file share authentication
`aadClientSecret`	Entra ID app registration secret

YAML variables take precedence over pipeline variables, so declaring these in the variables file would quietly override whatever you set in the UI. Keep them in the pipeline UI, a variable group, or Key Vault.

All three secrets stored as secret pipeline variables, not in YAML.

Last, fill in infrastructure/hybrid-logicapp-parameters.json with your connected environment name and resource group, the custom location ID, the file share details, and the Entra ID identifiers. Most of these are already populated from your wizard selections.

Step 6 — Create and run the CI pipeline

Go to Pipelines > New pipeline > Azure Repos Git, select your repository, choose Existing Azure Pipelines YAML file, and point it at /deployment/<logic-app-name>/pipelines/CI-pipeline.yml. Then run it.

When it finishes you should see two published artifacts: the logic app ZIP and the infrastructure templates.

The CI run publishes both the application package and the infrastructure templates.

Step 7 — Create and run the CD pipeline

Create a second pipeline pointing at CD-pipeline.yml.

Before the first run, open the CD YAML and change the pipeline resource to match the name of your CI pipeline:

resources:
  pipelines:
  - pipeline: cipipeline
    # TODO: Update with the name of your CI pipeline
    source: CI Pipeline

Then run it. The steps run in order: infrastructure deployment, then release.

A successful CD run. The managed connections step is skipped, as expected.

Verify the deployment

In the Azure portal, open your Logic App (Hybrid) resource. Open the Workflows blade to confirm the workflows are there, then trigger one and check the run history.

The deployed workflows, listed and enabled on the Hybrid logic app.

Making changes later

Which pipeline you need depends on what you changed.

You changed	Run
Workflow definitions or connections	CI, then CD
ARM template or `hybrid-logicapp-parameters.json`	CI, then CD
CD variables or secrets only	CD only

The middle row is the one that catches people out. CD reads the ARM template from the artifact that CI published, not from the repository:

csmFile: '$(Pipeline.Workspace)/cipipeline/infrastructure/hybrid-logicapp-template.json'

An infrastructure change that is committed but not rebuilt through CI will not be picked up, so run CI first.

Troubleshooting

Not found SourceFolder in the Hybrid Build task: sourceFolderName does not match the folder in your repository that contains host.json. Remember it is the project folder, not the deployed logic app name.
<path>/workflowparameters does not exist: The deployment/<logicAppName>/ path is derived from logicAppName. If you rename the logic app, rename the generated folder to match, otherwise the build will not find the deployment assets.
Failed to check the resource group status. Error: {"statusCode":400}: Usually a placeholder left behind in subscriptionId. A malformed subscription value produces an invalid ARM URL, and the request fails with a 400 before authentication is even attempted.
AADSTS7000222: The provided client secret keys for app '...' are expired: The client secret behind the service connection has expired. Create a new secret on the app registration and update the service connection. If you would rather not track expiry dates at all, use workload identity federation for the ARM connection.
Unknown task AzureLogicAppsHybridBuild@0: The Azure DevOps extension is not installed in the organization, or the pipeline is running in a different organization than the one it was installed into.

Wrapping up

The generated pipelines package your workflows, deploy the Hybrid logic app infrastructure, and publish the application through its authenticated ZIP deploy endpoint. With the environment details and service connections configured, you can use the same process for subsequent deployments.

If you try this out and hit something we have not covered, let us know in the comments.

References

Azure Logic Apps documentation: learn.microsoft.com/azure/logic-apps
Connect to Microsoft Azure with an ARM service connection: learn.microsoft.com/azure/devops/pipelines/library/connect-to-azure
Set up your infrastructure for Standard logic app workflows with hybrid deployment
Azure Arc Jumpstart: Hybrid deployment for Azure Logic Apps on AKS
Azure Logic Apps Standard Tasks extension on Visual Studio Marketplace

From Form to Action: A Governed, Event-Driven AI Intake Pipeline with Azure Integration Services

BrittanyPugh — Fri, 09 Oct 2026 22:00:58 GMT

A production-minded reference architecture using Azure Integration Services and Microsoft Foundry to turn document-heavy intake into governed, traceable work.

TL;DR: Calling a model is one step in AI-powered intake. Production readiness depends on everything around the model: authenticated entry, controlled model consumption, durable asynchronous processing, explicit failure handling, and one correlation ID carried from the gateway to the final event. This post walks through a permit-intake reference architecture on Azure Integration Services and a companion repository you can run offline, without an Azure subscription.

The Problem: Intake is where AI Prototypes Stall

Many teams have built an AI prototype that reads a scanned form, extracts the key fields, and returns clean, structured data. That prototype proves the model can do the job. Taking it to production raises a different set of questions:

Who is allowed to call this, and how many times per minute?
What happens when the model returns a 429 or the CRM is down for maintenance?
Which team consumed those tokens?
Can you show me everything that happened to application #00417?
Who is notified when a record is created, and what breaks when we add another subscriber?

None of those questions is about the model, yet each one can decide whether the solution ships.

The underlying customer problem is broader than “How do we read a form?” It’s “How do we accept responsibility for a submission, process it reliably across slow or unavailable dependencies, and give applicants and operators a trustworthy status?” That framing moves the design from a single AI call to a governed system of connected services.

In this post, I use a fictional county’s building-permit intake as the running example. A resident submits a permit packet, and the county needs to validate it, extract the key fields, score it against intake policy, record it in a case system, and notify the right people, with a complete audit trail. The same shape appears in insurance first notice of loss, benefits enrollment, supplier onboarding, and claims intake. The repository keeps the domain in schemas and configuration: replace the schemas and labels, and keep the boundaries.

My thesis is simple: the hard part of production AI intake is connecting the services around the model reliably and under governance, not calling the model. The model is one component of the system. It isn’t the system.

Scope note: This is a production-minded reference architecture, not a production-ready template. The people, permit data, identifiers, and URLs in this post are synthetic, and the screenshots and trace rows show only that synthetic data. The repository favors demonstration clarity: public endpoints, simple SKUs, and simulated fallbacks.

Architecture at a Glance

Architecture diagram. A permit portal calls the Permits API in Azure API Management, which routes to a Logic App and then to a Service Bus queue with a dead-letter subqueue. An Azure Function extracts fields with Document Intelligence, gets an advisory compliance score from a Microsoft Foundry model through the API Management AI gateway, writes a record through a case-system adapter, and publishes a PermitCreated event to Event Grid, which fans out to a notification webhook and an analytics queue. Application Insights and Log Analytics join intake and processing with one correlation ID.

Figure 1. The governed, event-driven permit-intake flow. One correlation ID follows the permit from the gateway to the published event.

The design separates the acceptance path from the processing path. API Management owns the caller-facing contract and hands the work to a queue. Slow or failure-prone work happens after that hand-off. The flow reads left to right:

Portal → API Management → Logic App → Service Bus → Function → Case system → Event Grid → Subscribers │ Document Intelligence + Foundry model (through the AI gateway)

Responsibility	Service	Why this service
Governed front door and AI gateway	Azure API Management	One policy boundary for business APIs and model APIs
Low-code validation, enrichment, and routing	Azure Logic Apps	Business-visible run history; easy to change routing rules
Durable hand-off and back-pressure	Azure Service Bus	Retries, duplicate detection, and dead-lettering
Processing worker	Azure Functions	Scales with queue depth; runs the shared orchestrator
Field extraction	Azure Document Intelligence	Layout and key-value extraction from the packet
Policy-oriented scoring	Azure OpenAI in Microsoft Foundry Models	Rubric-based completeness and consistency review
Fan-out to downstream consumers	Azure Event Grid	Decoupled subscribers via CloudEvents
One correlation ID across the flow	Application Insights	End-to-end transactions plus one KQL join
Discovery and reuse	Azure API Center	A catalog of the Permits and model APIs

The case-system box is deliberately not a CRM product. The repository’s crm.py is an adapter: an in-memory stub by default, or an HTTP call to whatever CRM_BASE points at. Swap in Dynamics 365 or your records system without changing the orchestration contract.

Let’s walk through the design decisions that matter most.

API Management is more than a Proxy

API Management is often introduced as a proxy. In this architecture, it’s the governance boundary, and it governs two surfaces.

Diagram of two API surfaces governed by one API Management instance: the Permits API with token validation, rate limiting, and a correlation ID, and the Azure OpenAI v1 API with content safety, token limits, token metrics, and managed identity authentication. The Function’s scoring call routes back through the gateway to a Foundry model.

Figure 2. One gateway governs both the business API and the model API.

Surface 1: The Permits API

The Entra-protected variant of the inbound policy (permits-api.policy.xml, abridged) authenticates, throttles, and stamps a correlation ID before any backend code runs:

<inbound> <base /> <validate-azure-ad-token tenant-id="{{tenant-id}}" failed-validation-httpcode="401"> <audiences><audience>api://ais-demo-permits</audience></audiences> </validate-azure-ad-token> <rate-limit-by-key calls="60" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" /> <set-variable name="correlationId" value="@(context.Request.Headers.GetValueOrDefault("X-Correlation-Id", Guid.NewGuid().ToString()))" /> <set-header name="X-Correlation-Id" exists-action="override"> <value>@((string)context.Variables["correlationId"])</value> </set-header> <set-backend-service backend-id="permit-intake-logicapp" /> </inbound>

Three lines of intent are worth calling out:

validate-azure-ad-token rejects missing, invalid, or expired Microsoft Entra tokens with a 401 at the edge, so unauthenticated requests are rejected before they reach the backend. It knows the Entra issuers and signing keys for your tenant, so there’s no OpenID configuration URL to maintain.
rate-limit-by-key gives each consumer its own budget and returns 429 with Retry-After when it’s exceeded.
The correlation ID is created here (or accepted from a trusted caller) and echoed back on the 202 Accepted response. That single value is how you’ll find this permit later.

The deployed demo authenticates callers with API Management subscription keys and applies the same rate limit and correlation ID. To adopt the Entra variant, register an app for the api://ais-demo-permits audience, register a backend for the Logic App trigger, and then swap the policy.

Surface 2: The Model API (The AI Gateway)

The Function doesn’t call the model endpoint directly. It calls the Azure OpenAI v1 API through API Management, where a second policy applies (abridged):

In order, that policy:

llm-content-safety sends the prompt to Azure AI Content Safety, with Prompt Shields for injection attempts, and returns 403 for prompts that exceed the configured thresholds, before they reach the model.
llm-token-limit gives each consumer a tokens-per-minute budget (429) and a monthly token quota (403).
llm-emit-token-metric publishes token usage to Application Insights with a department dimension for showback or chargeback.
Managed identity authenticates the gateway to the model. The caller’s API Management subscription key is stripped, and local (key) auth is disabled on the Foundry resource, so the Function doesn’t hold a model key, which helps reduce the risk of key leakage.

The backend also has a circuit breaker that trips after three 429 or 5xx responses within a minute, pauses calls for a minute (or for the Retry-After period the model returns), and then resumes. The repository includes sample KQL for token monitoring and chargeback views.

The key point: conventional APIs and AI endpoints share one governed boundary. Your security team reviews one set of policies, and your platform team gets one place to see who is calling what.

Discovery: Azure API Center

API Management governs runtime traffic; Azure API Center is where people find the APIs. The repository links API Center to API Management, so the Permits APIs and the model API are cataloged with their definitions, lifecycle stage, and environment. Before a team builds another intake API or model proxy, they search the catalog and still call API Management at runtime. API Center isn’t on the request path.

Why the Flow is Asynchronous

The Permits API returns 202 Accepted with a correlation ID. It doesn’t wait for extraction, scoring, or the case system. That’s deliberate: document analysis, model calls, record writes, and notifications all have different latency and failure behavior, and holding the caller’s request open couples the caller to each of them.

Governance boundary: 202 means the platform durably accepted responsibility for the permit. It doesn’t mean extraction succeeded, a model approved anything, or a record was committed.

The repository enforces that literally. On the direct route (POST /permits), API Management writes to Service Bus and checks the answer before it says yes:

<send-request mode="new" response-variable-name="sbresponse" timeout="20" ignore-error="true">  </send-request> <choose> <when condition="@(context.Variables.GetValueOrDefault<IResponse>("sbresponse") == null || context.Variables.GetValueOrDefault<IResponse>("sbresponse").StatusCode != 201)"> <return-response> <set-status code="503" reason="Service Unavailable" />  </return-response> </when> </choose>

If Service Bus doesn’t confirm the write (an error status, a timeout, or no connection), the caller gets 503 with Retry-After, not a 202 for work that wasn’t queued.

Logic Apps: Validate, Enrich, Route

The Logic App workflow checks the payload, attaches the correlation ID, and hands the message to Service Bus with its own managed identity. If required fields are missing, it returns 400 immediately. Here’s the send step:

"Send_to_Service_Bus": { "type": "Http", "inputs": { "method": "POST", "uri": "https://@{parameters('serviceBusNamespace')}.servicebus.windows.net/@{parameters('permitsQueue')}/messages", "headers": { "BrokerProperties": "@{string(outputs('Broker_properties'))}" }, "body": "@outputs('Enrich_message')", "authentication": { "type": "ManagedServiceIdentity", "audience": "https://servicebus.azure.net" } } }

A preceding Broker_properties step sets MessageId to the parcel number and CorrelationId to the request’s correlation ID. Bicep loads this same workflow JSON when it deploys the Logic App, so each deployment applies the workflow definition from the repository.

Business analysts can read the run history in the Azure portal. If the county adds a new permit type or a routing rule, that change happens in the workflow, not in Python.

Design choice: The template deploys both routes. POST /permits-orchestrated goes through this Logic App. POST /permits uses a direct-enqueue policy that writes straight to Service Bus with the API Management managed identity; it’s the portal’s default and the route the trace below uses. Use the direct route when you don’t need low-code enrichment. Keep the Logic App when business users own the routing rules.

Service Bus: The Durable Hand-off

The permits-in queue is configured in Bicep with:

maxDeliveryCount: 5, a message is delivered up to five times (the first attempt plus four retries) before it’s moved to the dead-letter subqueue.
requiresDuplicateDetection: true with a 10-minute window, resubmitting the same messageId (the parcel number) doesn’t create a second message. See duplicate detection.
deadLetteringOnMessageExpiration: true, expired messages are kept for inspection instead of being dropped.

Functions: One Orchestrator, Many Hosts

A Service Bus–triggered Function (Python 3.14 on Flex Consumption) reads the correlation ID from the message properties and runs a framework-agnostic orchestrator. A message without a permit type raises an error, so Service Bus retries it and then moves it to the dead-letter queue.

The orchestrator does four things in order: extract → score → record → publish.

def process_permit(permit: dict, correlation_id: str) -> ProcessResult: extracted = document_intelligence.extract_fields(permit) # Document Intelligence compliance = ai_gateway.score_compliance(extracted) # model via the API Management AI gateway status = "IntakeReview" if compliance.score >= settings.compliance_threshold else "NeedsAttention" permit_id = crm.create_permit_record(extracted, compliance, correlation_id, status) event_grid.publish_permit_created(PermitEvent(permitId=permit_id, complianceScore=compliance.score, correlationId=correlation_id)) ...

Notice what the model doesn’t do: it doesn’t approve or deny anything. The score (0–100, against a rubric for completeness, consistency, and policy fit) only decides which human review state the permit lands in, IntakeReview or NeedsAttention, and that state is written to the case record. The call uses the Responses API on gpt-5.4-mini with structured output: the response must match a JSON schema (score, missing, flags), so downstream code receives a consistent, schema-validated shape. There’s no dated api-version to maintain:

client = OpenAI( base_url=f"{apim_base}/openai/v1/", api_key=subscription_key, default_headers={"api-key": subscription_key, "x-dept": "permitting"}, ) review = client.responses.parse( model="gpt-5.4-mini", instructions=RUBRIC, input=fields_json, text_format=Review, reasoning={"effort": "low"}, store=False, ).output_parsed

The caller authenticates to API Management, not to the model: the api-key header carries the caller’s API Management subscription key (the template renames this API’s subscription-key header to api-key). The OpenAI client requires api_key and also sends it as a bearer token, but the gateway replaces that header with its own managed-identity token before calling the model. For production, swap the subscription key for a Microsoft Entra token (api_key=token_provider) and validate it at the gateway.

The same process_permit function is hosted by the Function, by a FastAPI service for the portal, and by the Python SDK walkthrough. That keeps the demo, the tests, and the deployed worker running the same code.

Event Grid: Fan-out without Coupling

After the CRM write, the Function publishes a PermitCreated CloudEvent. Two subscribers react independently: an analytics/audit queue and, when you supply a webhook URL, a resident notification webhook. Each subscription makes up to 30 delivery attempts over 24 hours. Adding a third subscriber, such as a GIS update or an inspector scheduling system, is a new subscription. It’s not a change to the permit flow.

Commands and Events are Different Things

Service Bus carries a command: “process this permit.” Event Grid carries a fact: “this permit was created,” published only after the record write succeeds. Keeping them separate makes retries, ownership, and subscriber behavior easier to reason about, a poison message can be retried and dead-lettered without a PermitCreated event going out for work that didn’t finish. Four rules follow:

Message identity: a stable message ID (the parcel number) and the correlation ID as a message property. In the repository.
Idempotency: a redelivered message must confirm earlier work, not create a duplicate record. Production work.
Dead-letter ownership: someone watches the queue, reads the reason codes, and is authorized to replay. Operational.
Status: callers need a status resource (accepted, processing, needs review, completed, failed) that doesn’t expose document contents. Production works the repository returns only the correlation ID.

How Failures are Handled and What Still Needs Work

A production-minded design makes failure behavior explicit before the happy path is trusted. The table separates what the repository does today from what still belongs on the production path:

Failure	What happens in the repository	Still needed for production
Caller has no valid token	401 at API Management (Entra policy variant); no backend call	Entra validation on every public API
Caller exceeds its rate limit	429 with Retry-After	Per-consumer products and quotas
Payload missing required fields	Orchestrated route: 400 from the Logic App, passed back by API Management. Direct route: accepted, then dead-lettered by the Function if type is missing	The same validation on the direct route
Queue unavailable	Direct route: 503 with Retry-After. Orchestrated route: the Logic App run fails and returns an error. Neither returns 202	An alert on enqueue failures
Malformed message on the queue	Delivered up to five times, then dead-lettered (MaxDeliveryCountExceeded)	A named owner and a replay procedure
Prompt blocked by content safety, or monthly token quota spent	403 from the gateway; Service Bus redelivers the message, then dead-letters it	Route to NeedsAttention with a reason instead of dead-lettering
Model unavailable (429 or 5xx from the gateway or model)	The OpenAI client retries twice, then Service Bus redelivers the message and finally dead-letters it. The backend circuit breaker pauses calls to the model while it’s tripped	Route to NeedsAttention with the reason model_unavailable, keeping the deterministic validation results
Case system unavailable	The Function fails before publishing; the message is redelivered	An idempotency key on the record write
Event Grid unavailable after the record write	The Function fails; a retry can repeat the record write	A transactional outbox for the event
A notification subscriber is down	Event Grid retries that subscriber only (30 attempts over 24 hours)	—

Two rows deserve a closer look. Model unavailable: today, a model failure retries and then dead-letters the permit. A better design keeps the deterministic validation results, routes the permit to NeedsAttention with a reason such as model_unavailable, and never treats a missing score as approval. Case system unavailable: the record write is the commit point for PermitCreated, so the event must never go out before it. Idempotency keys plus an outbox let a committed record and its event be reconciled. A prototype doesn’t need these safeguards; a production service does.

AI is Optional and Bounded

The non-AI capabilities like durable acceptance, extraction, deterministic validation, the case record, and events are useful with generative AI turned off. The model’s score is advisory: it prioritizes review and surfaces gaps. It must never quietly become the approval decision.

Extraction output is evidence to validate, not ground truth.
Deterministic rules own required fields, allowed values, and hard policy constraints. In the repository, the Logic App rejects a packet without name or type, and the Function dead-letters a message without type. The model doesn’t enforce either rule.
The model’s output is schema-constrained (score, missing, flags) and labeled advisory.
Low scores, conflicting evidence, and model failures route to people.
Logs carry identifiers and stage outcomes, not document bodies.

Before any real workload, evaluate the scorer in Microsoft Foundry with synthetic or properly governed labeled data. The scorer is a direct model call through API Management, not a Foundry agent, so use dataset-based evaluators and graders, and keep an authorized person in the loop for consequential decisions.

Trace One Permit End to End

Governance is only useful if you can prove what happened. Here’s one synthetic permit created through the demo environment.

Submit. The client posts the permit to API Management: { "name": "[Applicant Name]", "type": "Building", "parcel": "AIS-TT-102242", "applicantEmail": "[Applicant Email]" }
Govern and accept durably. On the direct /permits route, API Management applies its policies, stamps a correlation ID, writes the message to permits-in, and only after Service Bus answers 201, returns 202 Accepted with X-Correlation-Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx.
Process. The Function picks up the message and extracts the fields. This run had no document attached, so it used the repository’s synthetic extraction fallback; attach a document URL to exercise Document Intelligence.
Score, behind content safety. The Function calls the model through the AI gateway. Content Safety and Prompt Shields screen the prompt first; then gpt-5.4-mini returns a score of 22 and lists missing applicant contact details and a project description. Status: NeedsAttention, which is the expected result for a packet missing those details. (Simulated mode scores the same packet 100.)
Record and publish. The case-system adapter creates P-E6980B0C, and the Function publishes PermitCreated; Event Grid delivers it to the analytics queue.
Reconstruct. One query returns the whole journey.

The portal shows the same journey to a business audience:

The Permit Intake Portal in simulated mode. An applicant, shown as the placeholder [Applicant Name], submits a building permit and the portal shows the correlation ID, the permit ID, an IntakeReview status, a compliance score of 100 out of 100, a published event, and a seven-row trace table from API Management through the Logic App, Service Bus, Document Intelligence, the AI gateway, the case record, and Event Grid, with an info button on each row.

Figure 3. The portal’s processing result and hop-by-hop trace. This screenshot is from simulated mode, so all values are synthetic and the applicant is shown as a placeholder.

In Application Insights the journey is two operations. The intake operation is the API Management request and its Service Bus write. The processing operation is one end-to-end transaction: the Function, its call back through the AI gateway, the Content Safety checks, the model call, and the Event Grid publish. The Service Bus hop doesn’t carry W3C trace context, so the correlation ID is the join key, API Management logs it as a header, and the Function’s log lines name it. This query finds the operations that mention it:

let cid = '<correlation-id>'; let hits = union AppRequests, AppDependencies, AppTraces, AppExceptions | where OperationId == cid or Message has cid or tostring(Properties) has cid; let ops = hits | where isnotempty(OperationId) and OperationId != '00000000000000000000000000000000' | distinct OperationId; union (union AppRequests, AppDependencies, AppExceptions | where OperationId in (ops)), (hits | where Type == 'AppTraces') | project TimeGenerated, Type, Name = coalesce(Name, Message, OuterMessage), ResultCode, DurationMs, AppRoleName | order by TimeGenerated asc

For the permit above, it returned:

Operation	Hop	Component	Result	Duration (ms)
Intake	POST /permits	API Management	202	1,471
Intake	POST /permits-in/messages	Service Bus enqueue	201	177
Processing	ServiceBusProcessor.ProcessMessage	Azure Functions	—	5,875
Processing	POST /openai/v1/responses	AI gateway (called by the Function)	200	4,542
Processing	POST /contentsafety/text:analyze	Content Safety	200	777
Processing	POST /contentsafety/text:shieldPrompt	Prompt Shields	200	235
Processing	POST /openai/v1/responses	Foundry model (gpt-5.4-mini)	200	2,705
Processing	POST /api/events	Event Grid publish	200	83

Durations come from one run in a demo environment, including cold starts. They aren’t performance figures.

Application Insights end-to-end transaction for the permit processor, listing each step in order: synthetic field extraction, the compliance-scoring call back through the API Management AI gateway, two Azure AI Content Safety checks, the gpt-5.4-mini model call, a compliance score of 22 with the missing items, the case record, the Event Grid publish, and a final trace line reporting permit P-E6980B0C for parcel AIS-TT-102242 with status NeedsAttention. Resource names and identifiers are redacted.

Figure 4. The processing operation for the same permit in Application Insights. The durations match the table above. Resource names and tenant identifiers are redacted.

When a caseworker asks, “What happened to application #00417?”, the answer can come from one query instead of separate log searches across teams.

Run it Locally, then Deploy it

The repository is designed so you can understand the architecture before you spend anything on Azure.

1. Offline Simulation (no Azure Subscription)

uv sync --extra dev # Python 3.14 cp .env.example .env # SIMULATED_MODE=true by default uv run ais-demo # runs steps B1–B8 end to end

In simulated mode, each adapter (Service Bus, Document Intelligence, the model, CRM, Event Grid, Azure Monitor) is replaced by an in-memory stand-in with the same interface. The walkthrough submits a permit, enqueues it, extracts and scores it, writes the record, publishes the event, dead-letters a deliberately malformed message, and prints the correlated trace. The test suite (uv run pytest) covers the same paths.

To see the business view, start the API and portal together:

./scripts/setup.sh ./scripts/app.sh start # API on :8000, portal on :5173 (Node.js 24 LTS)

2. Same Interface, Azure-backed Adapters

Each adapter module checks one setting:

if settings.simulated_mode or not settings.servicebus_fqdn: return _consume_simulated(handler) return _consume_live(handler, settings) # azure-servicebus + DefaultAzureCredential

Set SIMULATED_MODE=false, provide the endpoints, and the same orchestrator talks to real services. Live adapters authenticate with DefaultAzureCredential, so the deployed Function uses its managed identity for Service Bus, Document Intelligence, Event Grid, and Azure Monitor. Both Python hosts export OpenTelemetry to Application Insights, and the Function’s log lines name the correlation ID.

3. Deploy with Bicep and Clean up

az group create -n rg-ais-demo -l eastus2 az deployment group what-if -g rg-ais-demo \ --template-file infra/main.bicep --parameters infra/main.bicepparam az deployment group create -g rg-ais-demo \ --template-file infra/main.bicep --parameters infra/main.bicepparam # or: azd provision --preview && azd provision

One deployment creates and wires the whole stack: Service Bus and Event Grid (with the analytics subscription, plus the notification webhook subscription when you pass notificationWebhookUrl), Document Intelligence, a Microsoft Foundry resource with the gpt-5.4-mini deployment, the Logic App workflow, a Flex Consumption Function App on Python 3.14, API Management with all three APIs (/permits, /permits-orchestrated, and /openai) and their policies, API Center, and the managed-identity role assignments it needs. Local (key) auth is disabled on Service Bus, Event Grid, Document Intelligence, and the Foundry resource. The template defaults to the BasicV2 tier of API Management; the sample main.bicepparam sets the classic Developer tier to match the existing demo environment, so change apimSku for a new environment. For a faster inner loop, pass deployApim=false. After provisioning, publish the Function code; the deployment guide has the details, and a GitHub Actions workflow runs the same what-if and provision steps with OpenID Connect.

When you’re done:

az group delete -n rg-ais-demo --yes --no-wait

The repository also includes a demo track that tells the same story two ways: an Azure portal click-through for business stakeholders (steps A1–A15) and a Python SDK walkthrough for engineers (steps B1–B8).

Production Boundaries: What this Reference doesn’t Do

This repository is a production-minded reference architecture: it anticipates production concerns while staying candid about what it doesn’t prove. A production path starts from your organization’s requirements and platform standards. Here’s the gap:

Area	In the repository	Before production
Networking	Public endpoints	Private endpoints, virtual network integration, and a WAF in front of internal API Management (reference architecture)
Identity	Managed identity to Service Bus, Event Grid, Document Intelligence, and the Foundry resource, with local auth disabled; API Management subscription keys for callers (an Entra token policy is provided)	Microsoft Entra token validation on every public API; the Function’s API Management subscription key in Key Vault or replaced by Entra auth
AI safety	Content Safety and Prompt Shields at the gateway; structured output; advisory-only scoring	Tuned thresholds and blocklists, response-side checks, and offline and continuous evaluation gated in CI
Data retention	In-memory or simulated CRM	A real system of record with retention, residency, and deletion policies agreed with records owners
Consistency	Retries, duplicate detection, and dead-lettering	Idempotency keys and an outbox for the record write and event publish
Caller status	The correlation ID	A status resource (accepted, processing, needs review, completed, failed)
Access control	One demo subscription	Per-consumer products, least-privilege RBAC, and separated duties for operators and reviewers
Operational ownership	Demo scripts	Dashboards, alerts on dead-letter depth and token budgets, runbooks, and named owners for every queue
Human review	Score routes to a review state	Documented reviewer workflow, override capture, and periodic sampling of AI-assisted decisions

Production landing zone diagram with an edge web application firewall, API Management in a hub virtual network, application workloads in a spoke virtual network, and private endpoints for data, messaging, and AI services.

Figure 5. The same services in a network-isolated API Management landing zone.

The repository’s production path maps each of these items to the Azure Well-Architected Framework pillars. It also sketches how the AI gateway grows into a multi-region front door with backend pools, circuit breakers, and semantic caching, without changing the governance policies you already have.

Map the Article to the Repository

Article	Repository location
Shared pipeline	src/ais_demo/orchestrator.py
Governed intake (direct, orchestrated, Entra variant)	apim/policies/permits-api*.xml
AI gateway	apim/policies/aoai-api.policy.xml
Logic App workflow	integration/logicapp/permit-intake-workflow.json
Durable command and dead-lettering	src/ais_demo/integrations/service_bus.py
Extraction	src/ais_demo/integrations/document_intelligence.py
Advisory scoring	src/ais_demo/integrations/ai_gateway.py
Case-system adapter	src/ais_demo/integrations/crm.py
Events	src/ais_demo/integrations/event_grid.py
Trace join	src/ais_demo/integrations/monitor.py
Infrastructure	infra/main.bicep and infra/modules/
Runbooks	docs/deployment-guide.md and docs/demo-track.md
Production path	docs/production-path.md

Key Takeaways

Put the model behind the same gateway as your APIs. Content safety, token limits, usage metrics, and managed identity help turn model access into something you can govern and attribute.
Accept fast, process durably and mean it. Return 202 only after the queue confirms the message. That helps shield residents from downstream outages and gives operators a dead-letter queue to inspect instead of a lost request.
Keep AI advisory. Let the model route work to people. Don’t let it make the decision.
Create one correlation ID at the edge and carry it through each hop. It’s one of the simplest audit trails you can build.
Decouple what happens next. Event Grid lets new consumers subscribe without touching the intake flow.

What to do Next

Agree on the acceptance contract: exactly when 202 is returned and how callers check status.
Run the simulated portal and Python walkthroughs with one synthetic correlation ID.
Test the failure paths: queue unavailable, poison message, model unavailable, case system unavailable, and a trace gap.
Add idempotent record writes and an outbox for event publication.
Evaluate the advisory model separately from deterministic rules and human approval.
Complete an architecture, privacy, security, and Well-Architected review for your subscription before using real data.

Try It

Repository: github.com/honestypugh2/ais-demo. Start with uv run ais-demo, no Azure subscription required.
Adapt it: Change the schemas in src/ais_demo/schemas/permit.py, update USE_CASE_PROFILE and the samples in data/, and keep the topology.
Go deeper: AI gateway capabilities in API Management · Service Bus dead-letter queues · Event-driven architecture style · Investigate transactions in Application Insights
Related reading: Grounding Copilot Studio Agents with Azure AI Search and Foundry IQ

Models will change. The work around them is what moves intake from form to action: a governed front door, durable hand-offs, advisory scoring, and one correlation ID from submission to the final event. Clone the repository, run it offline, and adapt the schemas to your own intake process. Comments and questions are welcome below.

The sample code in this post and the companion repository is provided "as is" under the MIT license for demonstration purposes. It uses synthetic data only and isn't intended for production use without additional security, reliability, and compliance review. Nothing in this post is legal, compliance, security, or deployment assurance, and it doesn't represent a customer implementation. The county and applicant in this example are fictional. Check product availability, quotas, model access, and regional capabilities for your own subscription.

Microsoft Agent 365 and Azure API Management integration for MCP governance

santiagxf — Fri, 09 Oct 2026 20:18:42 GMT

As agents gain access to enterprise tools, organizations need consistent ways to govern what those agents can access and enforce those decisions at runtime

Today, we're announcing a new integration between Microsoft Agent 365 and Azure API Management now in public preview. The integration connects centralized governance in Agent 365 with runtime enforcement for MCP servers and tools through Azure API Management for V2 and AI Gateway tiers.

With this integration, AI administrators can discover and govern gateway managed MCP servers and tools from Agent 365 and application platform teams use Azure API Management, to enforce those access decisions at runtime. Microsoft Defender and Microsoft Purview add additional layers of protection by evaluating tool requests and results for threats and sensitive information risks.

Centralized governance, enforced at the gateway

Agent 365 and Azure API Management play complementary roles. Agent 365 defines governance intent, maintains inventory, and manages access decisions. Azure API Management enforces those decisions inline for traffic to MCP servers and tools.

Together, they connect the enterprise governance experience with the infrastructure platform teams already use to manage access to business systems. Administrators can make supported access decisions from Agent 365, while enforcement happens at the gateway in the customer's Azure environment.

For agents already using a configured gateway endpoint, that connection remains in place. Customers can extend governance to their existing gateway-managed tools without rearchitecting those agents or moving tools out of their Azure subscriptions.

Discover tools and control what agents can do

The integration brings together four key capabilities:

Discover existing gateways and MCP servers. After a one-time tenant-level consent, Agent 365 discovers supported Azure API Management resources and the MCP servers they expose, removing manual registration.
Maintain a centralized inventory. Administrators can find gateway-managed MCP servers in Agent 365 and inspect available metadata, bringing these assets into a shared governance experience.
Control access at the right level. Block or unblock an entire MCP server. With the Azure API Management AI Gateway tier (preview) they can apply more granular controls by blocking individual tools without disabling the server.
Use runtime signals for oversight. Tool activity observability on AI Gateway tier supports monitoring, auditing, and incident investigation, connecting access decisions with what happens at runtime.

Add protection before tools run and before results return

Controlling which tools agents can access is one part of the governance model. Organizations also need protection for information flowing through those tools .

The Agent 365 tool threat protection policy (supported in the AI Gateway tier) uses Microsoft Defender and Microsoft Purview capabilities to evaluate tool requests and results for risks such as malicious content, prompt injection, and exposure of sensitive information.

Platform teams can configure evaluation before tool invocation, after invocation, or at both stages. With blocking configured, pre-invocation evaluation can prevent a disallowed call from executing. Post-invocation evaluation can withhold unsafe results before they reach the agent.

Build on open standards and existing investments

This integration connects centralized governance with enforcement where agents access tools, while building on the infrastructure organizations already operate.

MCP provides a common interface for tool access. Azure API Management provides the gateway boundary for applying policy, security, and observability. Agent 365 brings those gateway-managed assets into a centralized governance experience, with Microsoft security capabilities adding protection along the tool-call path.

The goal is not to make every agent use the same runtime. It is to help organizations apply governance to tools reached through supported gateway endpoints, bringing AI administrators, platform teams, and security teams closer together, while preserving the existing architecture.

Get started

API Management v2 tiers support centralized MCP inventory and server-level blocking and unblocking through Agent 365.The AI Gateway tier adds more granular capabilities including individual-tool blocking, tool activity observability, and tool threat protection .

Start with the Agent 365 integration guide, explore tool threat protection with Defender and Purview, and configure your gateway in the AI Gateway portal.

💲Announcing Free Grant and Pricing for Logic Apps Automation

DivSwa — Mon, 19 Oct 2026 18:02:57 GMT

Today, we're announcing pricing for Azure Logic Apps Automation, now in public preview, along with monthly free grants that make it easier to start building, experimenting, and bringing automations to life.

Logic Apps Automation is Azure's fully managed platform for business process automation and orchestration, including AI-powered automation. It's built for every builder with an automation problem, not just developers, and the free grants make it easy to go from idea to a working automation without a purchase decision up front.

The free grant covers one managed environment per subscription and includes usage across key Logic Apps Automation capabilities, so you can start with your first use case, experiment with AI-powered automation, and run workloads in production within the included limits; then move to paid usage as your needs grow.

Start today @ https://auto.azure.com/

Start free with monthly grants

Every Azure subscription gets a monthly free grant across the platform. The only exception is Managed Environment which is a one-time free grant for first 60 days. When the usage stays within these limits you pay nothing. When it goes beyond these limits, you pay only for the additional usage.

Usage	Component	Monthly free grant (per subscription)
Core Platform	Managed environment	One environment, free for the first 60 days (2 months)
Core Platform	Workflow runtime	108,000 execution-seconds (about 30 hours)
Core Platform	Data retention	1 GB
Optional Capabilities	Managed connector calls	1,000 Standard + 500 Enterprise
Optional Capabilities	Knowledge storage	1 GB
Optional Capabilities	AI usage	1,100 AACs
Optional Capabilities	Isolated code execution	18,000 seconds (about 5 hours)

What this means in practice

Explore the platform, not a trimmed-down experience. The grants include workflow runtime, AI usage, knowledge, connectors, and sandboxed code, so you can explore every capability from day one.
Build and iterate without watching the meter. With approximately 30 hours of execution time included each month, you can author, test, and run workflows as you build out your automation.
Scale into paid usage as your needs grow. Grants reset every month, and you pay only for usage beyond them.

Simple, usage-based pricing

Beyond the included grants, Logic Apps Automation uses a pay-as-you-go pricing model across the capabilities your automations use.

Billing has two parts:

Core Platform: the managed environment, workflow runtime, and run-history retention that provide the foundation for your automations.
Optional Capabilities: AI usage, knowledge storage, isolated code execution via sandbox and managed connectors, billed only when your workflows use them.

For rates, regional pricing, and a worked monthly cost example, see Azure Logic Apps Automation pricing.

How does the free grant works

The free grant applies to the first environment you create in a subscription. Look for the Free tag next to an environment's name to see which is the free one

Free environment period: The managed environment is free for 60 days, starting from the time you create it.
Existing customers: If you already use Logic Apps Automation, create a new environment to use the free grant. The first new environment you create in your subscription receives it.
Track your usage: In your environment, go to Settings and select the Free Grants tab to see your monthly limits and how much you've used.

Important: Free grants are tied to the free environment. If you delete your free environment, you lose the ability to use the free grants, and you can't get them back by creating a new environment.

Availability

Logic Apps Automation is in public preview in Australia East, East Asia, North Central US, Southeast Asia, Sweden Central, UK South, and West US. Preview pricing and availability may change before general availability.

Get started

If you already have an Azure subscription, your included grants are available to help you start building today.

Create your first Automation project, start from a template or with the AI workflow assistant, and explore what you can build with Logic Apps Automation.

Share feedback or request a feature, or just let us know what you build with Automation!

Update network rules for the API Management service tag

Sreekanth_Thirthala — Wed, 07 Oct 2026 10:41:21 GMT

To improve Azure API Management resiliency and scalability, we’re expanding our infrastructure and adding control-plane IP addresses. These addresses are included in the ApiManagement service tag.

If you use VNet internal or VNET external with the classic (v1) tiers, check your network security groups (NSGs), user-defined routes (UDRs), and firewalls. Replace hard-coded API Management IP addresses with the service tag wherever supported.

Make this change by November 30, 2026, to avoid disruption to management access. If network rules block connectivity to the management endpoint after that date, you may be unable to manage your API Management configuration—such as APIs, operations, and policies—from the Azure portal or CLI. This change affects management-plane traffic only. Runtime traffic, including API calls to your services, is not impacted.

Find the ApiManagement tag in Microsoft’s Azure service tags overview or the latest Azure IP Ranges and Service Tags JSON download. If your firewall doesn’t support service tags, use the published list and keep your IP rules synchronized with its latest version. Don’t rely on a fixed, point-in-time IP list. During the transition, the service tag includes both existing and new addresses.

For reference: Use API Management in an internal virtual network

Logic Apps Aviators Newsletter - October 2026

WSilveira — Mon, 05 Oct 2026 15:00:00 GMT

In this issue:

Ace Aviator of the Month
News from our product group
News from our community

Ace Aviator of the Month

October 2026's Ace Aviator: Hicham Boutaleb

Hicham Boutaleb - Enterprise Integration & Azure Solution Architect @ 5-Nines Consulting

What's your role and title? What are your responsibilities?

I work as an Enterprise Integration Architect, helping organizations design, implement, and modernize integration platforms using Microsoft technologies. My responsibilities include defining architecture, leading technical delivery, supporting development teams, ensuring best practices around security and governance, and helping customers get the most value from Azure services such as Logic Apps, API Management, Service Bus, and Azure Functions.

Can you give us some insights into your day-to-day activities and what a typical day in your role looks like?

No two days are exactly the same, which is one of the things I enjoy most about my role.

A typical day usually involves a mix of:

- Designing integration and automation solutions.
- Reviewing architectures and code with project teams.
- Supporting customers in solving complex technical challenges.
- Running workshops and knowledge-sharing sessions.
- Evaluating new Azure capabilities and how they can benefit ongoing projects.
- Collaborating with business stakeholders to translate requirements into scalable technical solutions.

I also dedicate time to continuous learning because the cloud ecosystem evolves incredibly fast, and staying up to date is essential.

What motivates and inspires you to be an active member of the Aviators/Microsoft community?

The community is one of the best accelerators of professional growth. What motivates me most is the opportunity to learn from others while also giving back through sharing experiences, lessons learned, and practical solutions.

I believe that technology is not just about tools—it's about people. The Microsoft community creates an environment where professionals can collaborate, innovate, and help each other succeed. Seeing someone solve a problem using knowledge I've shared is incredibly rewarding.

Looking back, what advice do you wish you had been given earlier that you'd now share with those looking to get into STEM/technology?

I would tell my younger self:

Don't focus only on technology, focus on problem-solving and communication.

Technical skills are important, but the ability to understand business challenges, communicate clearly, and work effectively with others often has an even greater impact on your career.

I would also encourage people to:
- Stay curious and never stop learning.
- Build real projects rather than only collecting certifications.
- Don't be afraid of failure—every mistake is an opportunity to learn.
- Invest in your professional network early.

The technology will change throughout your career, but adaptability and curiosity will always remain valuable.

What has helped you grow professionally?

Several factors have contributed to my growth:

- Working on diverse and challenging projects.
- Learning from experienced mentors and colleagues.
- Being willing to step outside my comfort zone.
- Participating in technical communities and events.
- Maintaining a mindset of continuous improvement.

Some of my biggest learning moments came from difficult projects where I had to solve problems I had never encountered before. Those experiences often teach more than success alone.

If you had a magic wand that could create a feature in Logic Apps, what would it be and why?

If I had a magic wand, I'd add an AI-powered end-to-end message tracking feature in Logic Apps that automatically follows a message across all workflows and Azure services it traverses. It would provide a single, intelligent view of the entire journey, making troubleshooting and root-cause analysis much faster and easier.

News from our product group

Your Certificate Renewed. Your Gateway Didn't Notice.

Learn how certificate renewal can create outages when Azure Application Gateway does not detect an updated certificate in Azure Key Vault. The article explains certificate refresh behavior and practical steps for ensuring renewed certificates propagate reliably to dependent gateway infrastructure.

How to Validate That Your BizTalk SB-Messaging Adapter Is Really Using AMQP

Prepare BizTalk Server integrations for the retirement of the legacy Service Bus Messaging Protocol by confirming that the SB-Messaging adapter uses AMQP. This guide covers the required BizTalk Server 2020 hotfix and shows how to verify active AMQP-over-TLS connections on port 5671 across every relevant host and messaging configuration.

Migrate Data Ingestion from Data Collector to Log Ingestion - Part 2

Continue migrating from the deprecated Data Collector API to the Azure Monitor Log Ingestion API by handling its smaller payload limit. The article demonstrates how to calculate and split large datasets into appropriately sized chunks in Azure Logic Apps so ingestion requests remain below the 1 MB limit.

Bring Azure Logic Apps connectors into your .NET applications with the Azure Connectors SDK

Explore the preview Azure Connectors SDK for calling Azure Logic Apps connectors directly from .NET applications without hosting a workflow. Strongly typed asynchronous clients, Azure Identity integration, and support for managed identities make it easier to connect application code to Microsoft and third-party services.

Agentic Refactoring of Legacy Integration Workloads to Azure Logic Apps Standard

See how agentic AI can accelerate the refactoring of legacy integration workloads into Azure Logic Apps Standard. This Microsoft Azure Developers video explores an AI-assisted modernization approach for analyzing existing solutions and moving them toward cloud-native workflows.

Connect Azure Functions to SharePoint using Managed Connectors

Learn how Azure Functions can connect to SharePoint using managed connectors. This Microsoft Azure Developers video demonstrates how connector capabilities simplify authentication and integration between function code and SharePoint.

Connect SaaS & Enterprise Systems with Azure Functions

This Microsoft Azure Developers video showcases how Azure Functions can use managed connectors for scalable, event-driven automation. It demonstrates integration with services such as SharePoint and Teams, highlighting how triggers and actions can reduce the need for manual polling and simplify authentication handling. The session walks through building practical workflows that connect SaaS and enterprise systems using Azure Functions.

News from our community

Logic Apps Community Day — 3 December 2026

Post by Ahmed Bayoumy

Logic Apps Community Day returns on 3 December 2026 as a free, online event streamed live on YouTube. The program focuses on Logic Apps, the wider Azure integration stack, and AI patterns built on integration platforms. Organizers describe eight community speaking slots, combining longer sessions with lightning talks, and invite practitioners to submit examples, client cases, comparisons, or AI features. The event is intended for a worldwide audience and includes discussions, a published agenda, and opportunities for community members to share practical experience.

Azure Logic Apps: Workflow Automation, Enterprise Integration, Connectors, B2B, Security, Networking, Monitoring, DevSecOps, Governance, and AI-Enable

Post by Sanjeeve Kumar Gajadi

This extensive guide presents Azure Logic Apps as an enterprise orchestration and integration layer rather than only a visual automation tool. It discusses Consumption and Standard hosting, triggers, actions, connectors, API Management, Service Bus, Event Grid, SAP, B2B protocols, managed identities, private networking, monitoring, reliability, DevOps, governance, and cost management. The article also considers AI-enabled orchestration and human approval patterns. Its central guidance is to design workflows around business processes, resilience, security, observability, and operational ownership while moving complex computation to suitable application services.

Azure Logic Apps Handbook: 50 Expert Tips and Best Practices

Post by Sandro Pereira

Sandro Pereira introduces a free handbook containing 50 expert tips and best practices for Azure Logic Apps. The guide is aimed at architects, developers, integration specialists, DevOps engineers, and leaders working with cloud automation. Its coverage includes Logic Apps capabilities, practical use cases, workflow optimization, security, common pitfalls, and implementation strategies. The accompanying article explains that the handbook is intended to help readers design reliable, scalable, and maintainable workflows, and provides access to the downloadable resource through the linked publication.

Build and Debug Logic Apps Standard Locally in VS Code

Post by Stephen W. Thomas

Stephen W. Thomas demonstrates how to build and debug Azure Logic Apps Standard workflows locally in Visual Studio Code without deploying resources to Azure. The walkthrough covers installing the extension, creating a stateful workflow with built-in operations, using local storage emulation, and sending a request from Postman. It also shows how to pause workflow execution at a breakpoint and inspect the results. The accompanying guide helps developers reproduce the setup and explore a practical local development loop while avoiding Azure charges during development and debugging.

Azure API Management Premium v2 Workspaces and Dedicated Workspace Gateways in a Private Network

Post by Şahin Özdemir

Şahin Özdemir shares lessons from configuring Azure API Management Premium v2 workspaces and dedicated workspace gateways in a fully private network. The article covers Premium v2 virtual network integration, workspace isolation for multiple teams, internal-only workspace gateways, required Bicep resources and associations, and network security group rules. It also calls out deployment pitfalls and the less obvious Microsoft.ApiManagement/gateways/configConnections resource used to associate workspaces with gateways. The first part keeps API Management externally accessible while placing workspaces and their gateways inside the private network.

Getting Started with Logic Apps Standard (in 2026)

Video by Stephen W. Thomas

Stephen W. Thomas shows how to set up Azure Logic Apps Standard locally in Visual Studio Code in under five minutes with no Azure charges. The updated installation brings in the Azure Functions runtime, Azure tooling, C# support, and storage emulators. The video creates a local workspace using built-in connectors, starts the workflow with F5, copies its callable URL, and sends a request from Postman. It also demonstrates breakpoints, debugger variables, action inputs, and stepping into custom in-process C# code for a complete local development experience.

Bring Azure Logic Apps connectors into your .NET applications with the Azure Connectors SDK

David_Burg — Wed, 30 Sep 2026 19:29:35 GMT

Modern business applications rarely work in isolation. An order exception might need an email, a support case might need a Teams notification, and a completed document might need to be stored in SharePoint. Developers can build each integration directly against a service API, but that also means owning different authentication models, request and response shapes, pagination rules, and error handling for every service.

The Azure Connectors SDK brings the typed experience of a .NET client library to Connector Namespace, which makes the Logic Apps and Power Platform connector runtime available to developers as a programmable integration layer. Your application can call connector operations through generated clients and models while Azure manages the connection to the external service.

In this post, we will build a small Azure function app that reacts to a new email through a Connector trigger and sends a formatted review email through the Office 365 Outlook connector. The same pattern can then be extended to many other business systems.

Preview: Azure Connectors SDK is currently in preview. Preview features are provided without a service-level agreement and are not recommended for production workloads. APIs and setup steps can change before general availability.

Why this matters

Integration code often starts with one HTTP call and grows into a collection of service-specific concerns. The Azure Connectors SDK gives .NET developers:

Typed clients, request models, and response models generated from connector contracts
Async operations with cancellation-token support
Azure credential integration for authenticating the calling application
Consistent connector exceptions and diagnostics
Built-in retry support for transient failures
Pagination, binary payload, and dynamic-schema support where connectors expose them
OpenTelemetry integration for tracing connector calls
Access to a broad connector ecosystem that includes Microsoft 365, Azure services, data platforms, storage, messaging, and SaaS applications

The SDK does not put external-service credentials in your application. Instead, your code authenticates to a Connector Namespace connection. That connection holds the authorization for Office 365 Outlook or another target service.

Scenario: notify operations about an order exception

Imagine an order service that flags transactions for manual review by sending an email to an Office 365 mailbox. The subject identifies the order and the body briefly explains the exception:

To: orders@contoso.com
Subject: Order exception: SO-10482
Body: Customer requested a delivery-address change after payment.

Connector Namespace polls the mailbox for new messages matching the subject filter and calls an Azure function app's Connector trigger. The function reads the typed email payload and sends a formatted review email to a separate operations inbox. Unlike an HTTP-triggered function, there is no application endpoint or 202 Accepted response to invoke.

Prerequisites

You need:

An Azure subscription in which Connector Namespace is available
Permission to create Connector Namespace resources and connections
.NET 10 SDK
Azure Functions Core Tools v4
Azure CLI
Azure Developer CLI (azd) for deployment, or an existing .NET 10 isolated-worker function app
An Office 365 account that can authorize the connection and send email

At the time of writing, Connector Namespace is available in a limited set of preview regions. Confirm current region availability before creating the resource.

1. Create an Office 365 connection

First sign in and select the subscription that will own the Connector Namespace:

az login
az account set --subscription "<subscription-id>"

$subscriptionId = "<subscription-id>"
$resourceGroup = "<resource-group>"
$namespaceName = "<connector-namespace-name>"
$connectionName = "office365-orders"
$location = "<supported-azure-region>"
$apiVersion = "2026-05-01-preview"
$nsId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Web/connectorGateways/$namespaceName"

Create a Connector Namespace with a system-assigned managed identity:

$namespace = @{
    location = $location
    identity = @{ type = "SystemAssigned" }
    properties = @{}
} | ConvertTo-Json -Depth 5 -Compress

$tempFile = Join-Path $env:TEMP "connector-namespace.json"
[System.IO.File]::WriteAllText($tempFile, $namespace)
az rest --method PUT `
    --uri "https://management.azure.com${nsId}?api-version=$apiVersion" `
    --body "@$tempFile" `
    --headers "Content-Type=application/json" `
    --output none
Remove-Item $tempFile

Create the Office 365 connection:

$connection = @{
    properties = @{ connectorName = "office365" }
} | ConvertTo-Json -Depth 5 -Compress

$tempFile = Join-Path $env:TEMP "connector-connection.json"
[System.IO.File]::WriteAllText($tempFile, $connection)
az rest --method PUT `
    --uri "https://management.azure.com${nsId}/connections/${connectionName}?api-version=$apiVersion" `
    --body "@$tempFile" `
    --headers "Content-Type=application/json" `
    --output none
Remove-Item $tempFile

The new connection is not authorized yet. Request an OAuth consent link and open it in your browser:

$consentRequest = @{
    parameters = @(
        @{
            redirectUrl = "https://portal.azure.com"
            parameterName = "token"
        }
    )
} | ConvertTo-Json -Depth 5 -Compress

$tempFile = Join-Path $env:TEMP "connector-consent.json"
[System.IO.File]::WriteAllText($tempFile, $consentRequest)
$consent = az rest --method POST `
    --uri "https://management.azure.com${nsId}/connections/${connectionName}/listConsentLinks?api-version=$apiVersion" `
    --body "@$tempFile" `
    --headers "Content-Type=application/json" `
    --output json | ConvertFrom-Json
Remove-Item $tempFile

Start-Process $consent.value[0].link

Complete the sign-in and consent flow. Then verify that the connection reports Connected:

az rest --method GET `
    --uri "https://management.azure.com${nsId}/connections/${connectionName}?api-version=$apiVersion" `
    --output json |
    ConvertFrom-Json |
    Select-Object -ExpandProperty properties |
    Select-Object -ExpandProperty statuses

2. Allow your local identity to call the connection

OAuth consent authorizes the connection to call Office 365. A separate access policy authorizes your application to call the connection. This distinction is important: without the policy, the runtime call fails with HTTP 403 and a missing connection ACL message.

Add an access policy for the identity currently signed in to Azure CLI:

$userObjectId = az ad signed-in-user show --query id --output tsv
$tenantId = az account show --query tenantId --output tsv

$policy = @{
    properties = @{
        principal = @{
            type = "ActiveDirectory"
            identity = @{
                objectId = $userObjectId
                tenantId = $tenantId
            }
        }
    }
} | ConvertTo-Json -Depth 6 -Compress

$tempFile = Join-Path $env:TEMP "connector-policy.json"
[System.IO.File]::WriteAllText($tempFile, $policy)
az rest --method PUT `
    --uri "https://management.azure.com${nsId}/connections/${connectionName}/accessPolicies/local-dev?api-version=$apiVersion" `
    --body "@$tempFile" `
    --headers "Content-Type=application/json" `
    --output none
Remove-Item $tempFile

Access-policy changes can take a few minutes to reach the connector runtime.

Finally, retrieve the connection runtime URL. Treat this value as application configuration rather than source code:

$connection = az rest --method GET `
    --uri "https://management.azure.com${nsId}/connections/${connectionName}?api-version=$apiVersion" `
    --output json | ConvertFrom-Json

$connectionRuntimeUrl = $connection.properties.connectionRuntimeUrl

3. Create the Azure function app

Create an isolated-worker function app with the current Core Tools template. Some Core Tools v4 versions do not offer net10.0 as a func init --target-framework option; use the .NET 9 template, then change the generated project's TargetFramework to net10.0 before building:

func init ConnectorsSdkOrderAlerts --worker-runtime dotnet-isolated --target-framework net9.0
Set-Location ConnectorsSdkOrderAlerts

In ConnectorsSdkOrderAlerts.csproj, set:

<TargetFramework>net10.0</TargetFramework>

Add the connector packages:

dotnet add package Azure.Connectors.Sdk --version 0.13.0-preview.1
dotnet add package Azure.Identity
dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Connector --version 0.2.0-alpha

Register an Azure credential and only the connector client this function needs. DefaultAzureCredential can use your Azure CLI identity locally and the function app's managed identity in Azure:

using Azure.Connectors.Sdk;
using Azure.Core;
using Azure.Identity;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices((hostContext, services) =>
    {
        services.AddSingleton<TokenCredential>(new DefaultAzureCredential());
        services.AddOffice365Client(
            hostContext.Configuration.GetSection("Connectors:Office365"));
    })
    .Build();

host.Run();

Add the function. The Connector trigger binds the OnNewEmailV3 callback to a typed payload. Filter the subject again in code, HTML-encode untrusted email fields, and send the review message through the generated SendEmailInput model:

using System.Text.Encodings.Web;
using Azure.Connectors.Sdk.Office365;
using Azure.Connectors.Sdk.Office365.Models;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Extensions.Connector;

public sealed class OperationalAlertFunctions
{
    private const string SubjectPrefix = "Order exception:";
    private readonly Office365Client _office365Client;

    public OperationalAlertFunctions(Office365Client office365Client)
    {
        this._office365Client = office365Client;
    }

    [Function("OnOrderExceptionEmail")]
    public async Task OnOrderExceptionEmailAsync(
        [ConnectorTrigger] Office365OnNewEmailTriggerPayload payload,
        CancellationToken cancellationToken)
    {
        foreach (var message in payload.Body?.Value ?? [])
        {
            if (message?.Subject?.StartsWith(
                    OperationalAlertFunctions.SubjectPrefix,
                    StringComparison.OrdinalIgnoreCase) != true)
            {
                continue;
            }

            var orderId = message.Subject[OperationalAlertFunctions.SubjectPrefix.Length..].Trim();
            if (string.IsNullOrWhiteSpace(orderId))
            {
                continue;
            }

            var email = new SendEmailInput
            {
                To = "operations@contoso.com",
                Subject = $"Order {orderId} requires review",
                Body = "<h2>Order review required</h2>" +
                    $"<p><strong>Order:</strong> {HtmlEncoder.Default.Encode(orderId)}</p>" +
                    $"<p><strong>From:</strong> {HtmlEncoder.Default.Encode(message.From ?? string.Empty)}</p>" +
                    $"<p><strong>Reason:</strong> {HtmlEncoder.Default.Encode(message.BodyPreview ?? string.Empty)}</p>"
            };

            await this._office365Client.SendEmailAsync(email, cancellationToken);
        }
    }
}

Use a monitored mailbox or folder separate from the operations inbox. Keep the outgoing subject different from the trigger's subject filter so the notification cannot trigger itself. For production workloads, account for repeated callbacks and partial failures within a batch before performing non-idempotent actions such as sending mail.

4. Deploy and register the Connector trigger

Keep the runtime URL out of source control. Set it for local development, then deploy the function app with a system-assigned managed identity and the same setting in its application configuration:

$env:Connectors__Office365__ConnectionRuntimeUrl = $connectionRuntimeUrl

The public Office 365 connector-trigger sample is a downloadable .NET 10 function app with deployment infrastructure, an OnNewEmail binding, and post-deploy trigger registration. Use its azd up workflow or deploy this function app through your existing pipeline. A locally running Functions host is not reachable by the Connector Namespace polling callback unless you provide a secure public callback endpoint.

Once the function app is deployed, add its managed identity to the connection's access policies, just as you added your CLI identity for local development. For a system-assigned identity, get its principal ID and use it in the access policy from step 2 instead of $userObjectId:

$functionAppName = "<function-app-name>"
$functionObjectId = az functionapp identity show `
    --resource-group $resourceGroup --name $functionAppName `
    --query principalId --output tsv

$policy = @{
    properties = @{
        principal = @{
            type = "ActiveDirectory"
            identity = @{
                objectId = $functionObjectId
                tenantId = $tenantId
            }
        }
    }
} | ConvertTo-Json -Depth 6 -Compress

$tempFile = [System.IO.Path]::GetTempFileName()
try {
    [System.IO.File]::WriteAllText($tempFile, $policy)
    az rest --method PUT `
        --uri "https://management.azure.com${nsId}/connections/${connectionName}/accessPolicies/order-alert-function?api-version=$apiVersion" `
        --body "@$tempFile" `
        --headers "Content-Type=application/json" `
        --output none
}
finally {
    Remove-Item $tempFile
}

Obtain the Connector extension's system key and the function app's actual default hostname, then construct the callback URL for the deployed function. Do not assume that the hostname is <function-app-name>.azurewebsites.net; the default hostname format can vary:

$connectorExtensionKey = az functionapp keys list `
    --resource-group $resourceGroup --name $functionAppName `
    --query "systemKeys.connector_extension" --output tsv
$functionAppHostname = az functionapp show `
    --resource-group $resourceGroup --name $functionAppName `
    --query "defaultHostName" --output tsv
$callbackUrl = "https://$functionAppHostname/runtime/webhooks/connector?functionName=OnOrderExceptionEmail&code=$connectorExtensionKey"

The system key is a secret. Do not log, publish, or commit the callback URL. Create the Office 365 polling trigger config using the same connection and a subject filter matching the incoming order messages:

$triggerConfig = @{
    properties = @{
        operationName = "OnNewEmailV3"
        connectionDetails = @{
            connectorName = "office365"
            connectionName = $connectionName
        }
        notificationDetails = @{
            callbackUrl = $callbackUrl
            httpMethod = "Post"
        }
        parameters = @(
            @{ name = "folderPath"; value = "Inbox" }
            @{ name = "subjectFilter"; value = "Order exception:" }
        )
        metadata = @{
            destinationType = "functionApp"
            functionAppName = $functionAppName
            functionAppResourceGroup = $resourceGroup
            functionAppSubscriptionId = $subscriptionId
            functionName = "OnOrderExceptionEmail"
            recurrenceFrequency = "Minute"
            recurrenceInterval = "5"
        }
    }
} | ConvertTo-Json -Depth 6 -Compress

$tempFile = [System.IO.Path]::GetTempFileName()
try {
    [System.IO.File]::WriteAllText($tempFile, $triggerConfig)
    az rest --method PUT `
        --uri "https://management.azure.com${nsId}/triggerConfigs/order-exception-email?api-version=$apiVersion" `
        --body "@$tempFile" `
        --headers "Content-Type=application/json" `
        --output none
}
finally {
    Remove-Item $tempFile
}

Confirm that the trigger config reports Enabled. Send a test email to the monitored mailbox, and allow for the polling interval before checking the function logs and the operations inbox:

az rest --method GET `
    --uri "https://management.azure.com${nsId}/triggerConfigs/order-exception-email?api-version=$apiVersion" `
    --query "properties.{operation:operationName,state:state}" `
    --output table

Confirm all three outcomes before considering the test complete:

The trigger config is Enabled and the function logs show the invocation.
The operations inbox receives a review email with the expected order ID and reason.
Unrelated messages do not produce review emails.

From local development to Azure

For a deployed function app, use its managed identity instead of a developer identity:

Enable a system-assigned or user-assigned managed identity on the function app.
Add that identity as an access policy on the Connector Namespace connection.
Register DefaultAzureCredential or ManagedIdentityCredential as the TokenCredential.
Store the connection runtime URL in function app configuration.
Protect the Connector trigger callback with the Connector extension system key; use a stronger authorization model for production as appropriate.

The external-service credential remains in the connector connection. The function app presents its Azure identity when it calls the runtime URL. The Connector Namespace uses the callback URL and its system key to invoke the function.

Go beyond email

The order-alert example is intentionally small, but the programming model supports much broader integration scenarios:

Microsoft 365: work with Outlook, SharePoint, Teams, OneDrive, Excel, Planner, Forms, and Microsoft Entra ID-backed operations.
Azure services: connect to Blob Storage, queues, tables, Event Grid, Event Hubs, Service Bus, Key Vault, Azure Monitor Logs, and Azure Data Factory.
Business applications: integrate with Salesforce, Dynamics 365, Jira, ServiceNow-style workflows, DocuSign, Zendesk, and other SaaS systems represented in the connector catalog.
Event-driven applications: register polling triggers that call back to an Azure function app when connector events occur.
Data-rich APIs: consume paginated operations, binary content, and operations whose input or output schema is resolved dynamically.
Observable integrations: capture connector activity in distributed traces with OpenTelemetry.

Because connector clients are typed, developers can discover operations through IntelliSense and keep connector calls alongside the rest of their application code. The connection layer handles authorization to the external system, while Azure identity and access policies govern which application may use that connection.

Troubleshooting

The call returns 403 with “missing connection ACL.”
The external OAuth connection may be healthy, but the calling Azure identity is not authorized. Add an access policy for the Azure CLI user during local development or the workload managed identity after deployment. Allow time for the policy to propagate.

The connection remains in an error state.
Complete the OAuth consent flow and query the connection again. Make sure the account used for consent has access to the target service.

The client fails during startup because the runtime URL is missing.
Make sure Connectors__Office365__ConnectionRuntimeUrl is present in the process environment. In a larger application, register only the connector clients whose configuration is available.

Authentication works locally but fails in Azure.
The local Azure CLI user and the function app managed identity are different principals. Add a separate connection access policy for the function app identity and use a managed-identity-capable credential in the deployed host.

The email trigger does not fire.
Verify the trigger config is Enabled, its operation is OnNewEmailV3, its folderPath and subjectFilter match the test email, and its callback uses the deployed function's OnOrderExceptionEmail name and Connector extension system key. Polling is not instantaneous.

Get started

Explore the Azure Connectors SDK repository, try the samples, and tell us which connectors and application patterns would be most useful for your team.

Migrate Data Ingestion from Data Collector to Log Ingestion - Part 2

mshboul — Thu, 24 Sep 2026 15:05:05 GMT

In Part1, we discussed how to use HTTP action to migrate from the deprecated Data Collector API to Log Ingestion API.

However, since the deprecated Data Collector API was allowing message payload up to 30MB, some migration scenarios encountered issues; since the new Log Ingestion API has only 1MB payload limit. This applies to both HTTP action, and the preview (Log Ingestion connector)

Azure Monitor service limits - Azure Monitor | Microsoft Learn

When sending payload larger than 1MB, the HTTP action would fail with the error:

In order to overcome this, we can chunk the array payload, before calling the Ingestion API. We need to chunk the array payload, so each produced chunk is around 800KB

To do this, you can divide the size of your full payload, by the number of records it has, and this would give an average record size. Then divide 800,000 bytes with the average record size, and this will give you the chunk size.

For example, if your payload size is 1,200,259 bytes, and the number of records is 2500, then the average record size is:
1,200,259 / 2,500 =~ 480 bytes

To find the chunk size, we divide 800,000 bytes by 480 bytes

800,000 / 480 =~ 1666 records.

So if we send around 1600 records, this should be less than 1MB.

To chunk your array payload, we can use the chunk expression inside a compose action.

You can use the expression below for chunking inside the compose action:

After the compose action, add for-each action, and use the output of the compose action as an input:

Inside the for-each, use the normal HTTP to send the logs, and in the body, choose the for-each current item

How to Validate That Your BizTalk SB-Messaging Adapter Is Really Using AMQP

hcamposu — Thu, 24 Sep 2026 04:15:15 GMT

On September 30, 2026, Azure Service Bus stops accepting the Service Bus Messaging Protocol (SBMP) — the protocol the BizTalk SB-Messaging adapter has always used. The failure mode is not a warning in a log file; it is a refused connection. To keep those integrations running, a BizTalk Server 2020 hotfix adds a new Azure.Messaging.ServiceBus AMQP implementation to the adapter in place of the legacy SBMP path.

This post walks through how to validate the hotfix was successfully deployed and is using AMQP and not SBMP.

Required baseline: BizTalk Server 2020 with Cumulative Update 6 or Cumulative Update 7 installed, plus the SB-Messaging AMQP hotfix — KB5091379, obtained by opening a Microsoft support case. The hotfix is not offered through Windows Update or the regular CU download, and it will not install on a CU5 or earlier baseline.

Every node in the BizTalk group needs it. A multi-server group will happily run the affected host instance on an unpatched node, and your test may land on the one server where the fix is not active. Patch and restart host instances everywhere, then record the edition, CU level, hotfix number, and component build per server.

Hotfix location: https://1drv.ms/f/c/cac4b5f5988b8228/IgCrzn_KTaZ8T5tuKmcdPgXxARuOLcGHDhxVLgeysj44GWE?e=w5AcpM

Once the baseline is confirmed, test in a non-production environment that reproduces production topology, authentication, and the full network path — proxy, firewall, private endpoint, and DNS. And list every materially different configuration you intend to validate: each send port and receive location, queue, topic, and subscription usage, 32-bit versus 64-bit hosts, and features such as sessions, ordered delivery, or transactions. A green result on one port does not validate the others.

Method 1: Verify the active connection on port 5671 (recommended)

The adapter selects AMQP over TCP, and Azure Service Bus uses TCP port 5671 for AMQP over TLS. Correlating an established 5671 connection with the correct BTSNTSvc or BTSNTSvc64 process demonstrates that the BizTalk host is using the AMQP transport. Run elevated PowerShell while the receive location is enabled and actively polling:

$hostProcesses = Get-Process BTSNTSvc, BTSNTSvc64 -ErrorAction SilentlyContinue Get-NetTCPConnection -State Established -RemotePort 5671 | Where-Object OwningProcess -in $hostProcesses.Id | ForEach-Object { $process = Get-Process -Id $_.OwningProcess [pscustomobject]@{ Process = $process.ProcessName ProcessId = $_.OwningProcess LocalAddress = $_.LocalAddress LocalPort = $_.LocalPort RemoteAddress = $_.RemoteAddress RemotePort = $_.RemotePort State = $_.State } }

Expected result:

Process is BTSNTSvc or BTSNTSvc64.
Remote port is 5671.
State is Established.
The remote address resolves to or corresponds to the Service Bus namespace.

What an empty result means: not much, on its own. An empty result is inconclusive, not a failure. Confirm the port or receive location is enabled, the host instance is running, traffic is actually flowing during the check, and that DNS, firewall, or private endpoint rules permit the connection — then repeat. One important exception: if your environment routes AMQP over WebSockets on TCP 443, you should not expect a 5671 connection at all. In that case skip to Method 2.

Method 2: Capture adapter traces

When the connection view is unavailable or ambiguous, the trace is the more definitive answer, because it shows which code path executed rather than which socket happened to be open. BizTalk adapter tracing uses ETW through BT.Trace.Tracer, and entries containing [SBMessaging-AMQP] confirm that the new AMQP-specific implementation executed.

Start BizTalk adapter tracing immediately before the test — not hours earlier.
Send or receive a single, uniquely identifiable test message through the target port or receive location.
Stop tracing as soon as the message completes.
Search the captured output for [SBMessaging-AMQP] entries inside the test window, and match them to the host instance and configuration you were exercising.

Method 3: Block the legacy SBMP ports

Methods 3 and 4 are corroborating tests, not proof, and belong in an isolated environment. Legacy SBMP commonly uses TCP ports 9350 through 9354. If the isolated AMQP workload continues to operate while those ports are blocked and TCP 5671 remains available, the result corroborates that the workload does not depend on SBMP. Record the original firewall rules before you start and restore them immediately afterwards — this test has a real blast radius if it escapes the test subnet.

Method 4: Large message functional test

In Basic and Standard tiers, the maximum message size is 256 KB, regardless of SDK or protocol, so this test does not apply there. In Premium, the legacy SBMP path supports messages only up to 1 MB, whereas AMQP supports larger messages up to the entity’s configured maximum of 100 MB. Successfully processing a Premium message larger than 1 MB therefore provides supplementary evidence that the adapter is using AMQP.

Read a failure carefully: entity limits, timeouts, and pipeline constraints all produce the same symptom, so a failed large-message test is not by itself evidence that the hotfix did not take. Verify payload integrity and the event log, then remove the test message and restore any temporary entity settings.

Do not stop at the protocol

Confirming that AMQP is in use answers the transport question. It does not answer whether your solution still behaves the same way. AMQP and SBMP differ in a handful of behavioural details, so before you call the validation complete, run the scenarios your integrations depend on and compare against a pre-change baseline:

Send and receive across each representative queue, topic, and subscription path, checking message body and application-property fidelity.
Peek-lock completion, abandon, defer, dead-letter, and retry behaviour, plus sessions, ordering, transactions, and duplicate detection where you use them.
Authentication renewal, and recovery after a host instance restart or a brief network interruption.

Throughput and latency within your accepted baseline, with no new event log errors, suspended instances, duplicates, or lost messages.

Your Certificate Renewed. Your Gateway Didn't Notice.

Madhura Amlekar — Thu, 17 Sep 2026 20:56:22 GMT

A setup that looks fine

API Management sits behind a global entry point like Traffic Manager or Front Door. Your custom domain, api.contoso.com, points at that entry point. APIM holds the same custom domain, with a certificate pulled from Key Vault. It works, for months.

Then the certificate renews, APIM tries to pick up the new version, and validation fails. Same infrastructure, same DNS, same everything.

It's not your fault. It's a mismatch between what validation checks and what your architecture actually looks like.

What is actually happening

APIM's custom domain validation expects a CNAME pointing directly at the gateway's default hostname, yourapim.azure-api.net. Put a global entry point in front, and your public CNAME points at that instead, which is the whole reason you deployed it. Validation resolves the domain, expects to find its own gateway, finds something else, and fails.

This is a documented constraint: in Standard v2 and Premium v2, APIM requires a publicly resolvable DNS name for the gateway endpoint. In practice, validation also doesn't accommodate a custom domain that resolves to Traffic Manager, Front Door, or Application Gateway sitting in front of the instance.

Figure 1. What validation expects to find, and what it finds when something sits in front.

Why it takes so long to notice

Day one, DNS may not yet point at the front door, or that layer went in afterwards, so validation passes. Everything's green.

Months later, the certificate renews and validation runs again. This time it fails. Nobody changed anything; the person who built the topology may have moved on.

Worse, when APIM can't fetch the new certificate, it doesn't fail loudly. It keeps serving the cached one. Your gateway stays up, monitoring stays green. It's a sync error in a log nobody watches. Only when the cached certificate actually expires does traffic get blocked, arriving as an outage with no obvious link to a failure from weeks earlier.

Figure 2. The gap between the change and the symptom is measured in months.

The fix: stop making the gateway own the name

Don't fight validation with DNS tricks or a manual repoint-rotate-repoint dance every cycle. Instead, put the custom domain on the thing users actually reach, and let APIM keep its default hostname.

If Front Door or Application Gateway is your entry point, that's where api.contoso.com and its certificate belong. That layer terminates TLS and forwards to APIM's default hostname. APIM has nothing left to validate against public DNS, so the problem disappears permanently, no scripts required. You lose nothing: APIM still enforces every policy, rate limiting, subscription keys, token validation.

Figure 3. Moving the custom domain to the edge removes the thing that fails.

Two things to weigh while you are there.

Order your edge deliberately. If you run a WAF, put it in front of everything. Don't let APIM absorb hostile traffic at the layer all your APIs depend on.
Check if you even need the front layer. Some teams run two APIM instances behind Traffic Manager or Front Door only because their tier lacked multi-region support or multiple custom hostnames. Higher tiers support both, which may let you collapse the whole topology into one instance.

An operational checklist

Whatever topology you land on, these are worth having in place.

Confirm the certificate is stored in Key Vault as a certificate, not as a secret. They look similar in the portal and behave differently here.
Check the managed identity used to reach Key Vault still exists, and that API Management has list and get permissions on secrets. There is a Restore action that repairs access automatically when the portal detects a problem.
If your instance is in a virtual network, confirm outbound connectivity to the Key Vault service tag. A blocked egress path produces the same silent staleness.
Read the sync logs. There is a View sync logs action that gives root-cause detail on failed synchronisation. It is the fastest route from something is wrong to here is what is wrong.
Auto-renewal pickup can take one to two days. Use Sync certificates to trigger it manually.
Alert on certificate expiry, not just on gateway health. The whole failure mode lives in the space between those two signals.
Test a rotation before you need one. Force a renewal in a non-production instance with your real topology in place. If it fails there, you have months to fix it rather than hours.

The takeaway

A validation check that passes at deployment is not the same as one that passes at renewal.

Anything that resolves a name, checks a permission or reaches a dependency is being evaluated again later, under conditions you cannot see from the deployment log.

If you are running API Management with a custom domain behind any kind of global entry point, you can find out today whether your next rotation will succeed. That is a much better day to discover it than the one where the cached certificate runs out.

References

Configure a custom domain name for your Azure API Management instance: Covers the CNAME requirement, Key Vault certificate options, the v2 tier public-resolvability limitation, certificate synchronization, and the troubleshooting actions referenced above.
Azure API Management v2 tiers: Sets out what the v2 tiers do and do not support, including the absence of multi-region deployment that leads teams to run several instances behind a load balancer.
Limitation for custom domain name in v2 tiers: The specific section behind the constraint described here, worth linking directly when you raise this with a team.
Feature-based comparison of Azure API Management tiers: The table to check before deciding whether a higher tier removes the need for a front layer entirely.
Configure Azure Front Door in front of Azure API Management: The reference for the topology recommended above, where the edge owns the custom domain.
Use API Management in a virtual network with Azure Application Gateway: The equivalent pattern where Application Gateway provides the web application firewall at the entry point.

Logic Apps Aviators Newsletter - September 2026

WSilveira — Mon, 07 Sep 2026 15:00:00 GMT

In this issue:

Ace Aviator of the Month
News from our product group
News from our community

Ace Aviator of the Month

September 2026's Ace Aviator: Parth Talaviya

Product Leader @ EG4 Eletronics

What's your role and title? What are your responsibilities?

AI-Powered Azure/.NET Solution Architect

I work as an Azure/.NET Solution Architect, combining technical leadership with building a Microsoft-focused boutique company. My work mainly revolves around application modernization and migration, cloud architecture, integrations, and team leadership. I also stay hands-on with development, architecture reviews, production troubleshooting, and mentoring developers.

Can you give us some insights into your day-to-day activities and what a typical day in your role looks like?

My day usually starts with thinking about how we can add more value to our clients' businesses. It includes reviewing project priorities, solving technical challenges, discussing architecture, supporting developers, and collaborating with stakeholders. I mainly work across .NET, Azure, APIs, integrations, DevOps, and AI automation, so every day brings something new to learn and solve.

What motivates and inspires you to be an active member of the Aviators/Microsoft community?

What really motivates me is how active and supportive the Microsoft community is. People are genuinely willing to help each other, share experiences, and solve problems together. Being able to use my own experience to help someone overcome a challenge genuinely makes my day, while learning from others keeps me motivated to continuously improve.

Looking back, what advice do you wish you had been given earlier that you'd now share with those looking to get into STEM/technology?

You don’t have to do everything alone. In technology, especially when you are stuck on a very specific problem, it can sometimes feel that way. Asking questions, learning from the community, and collaborating with others can make a huge difference.

I would also say: embrace AI early, but use it wisely. Don’t use AI only to generate code. Use it to understand concepts, challenge your thinking, explore better approaches, review your work, and become a better problem-solver.

What has helped you grow professionally?

Continuous learning and solving real-world challenges have helped me grow the most. Working on legacy modernization, cloud architecture, large-scale data systems, automation, and AI has taught me to think beyond writing code and understand the broader business impact.

Being part of a strong technical community has also helped significantly. Whenever you are stuck, there is often someone who has faced a similar challenge and is willing to share their experience.

If you had a magic wand that could create a feature in Logic Apps, what would it be and why?

I would create an AI-powered Copilot troubleshooting and self-healing assistant for Logic Apps. It could analyze failed workflows, understand the execution context, identify the likely root cause, suggest a fix, and provide safe recovery options. For complex integrations, this could save significant troubleshooting time and allow developers to focus more on building solutions rather than spending hours finding where something went wrong.

News from our product group

Use connectors with Managed Identity in the Logic Apps Standard extension

Managed Identity is Azure's built-in way to authenticate to Microsoft Entra-protected resources without storing credentials, secrets, or connection strings. Deployed Logic Apps have supported it for some time, and this post explains connector support in the Logic Apps Standard extension.

Introducing dependency telemetry in Application Insights for Azure API Management policies

Running API platforms at scale requires both handling load and understanding where inefficiencies occur. This post introduces dependency telemetry in Application Insights for Azure API Management policies to help teams identify performance bottlenecks.

Power Azure SRE Agent with the tools it needs

Azure SRE Agent is an AI-powered service designed to reduce operational toil. Teams can use it to investigate incidents, identify probable causes, and automate health-related operational work using connected tools.

Give your Copilot agents real tools, without hand-wiring MCP

GitHub Copilot coding agents can work independently on branches, but some tasks require access to external systems. This post shows how to equip agents with real tools without manually wiring Model Context Protocol integrations.

Zonal redundancy in API management Standard v2

APIs power modern mobile experiences, microservices, AI-driven applications, and business-critical integrations. This post explains zonal redundancy in Azure API Management Standard v2 for improving resilience as customers modernize their API platforms.

BizTalk Server 2020 End-of-Sale Announcement

Microsoft announces that BizTalk Server 2020 and Host Integration Server 2020 sales are expected to end on March 31, 2027. Existing licensed deployments can continue to be used, while mainstream support for BizTalk Server 2020 is scheduled through April 12, 2028. An optional paid extended-mainstream support offering is planned for eligible customers through April 10, 2030, with final terms to be published later. The post recommends beginning migration planning now, evaluating Azure Logic Apps Standard or Azure Logic Apps Hybrid, inventorying dependencies, and using the Logic Apps Migration Agent to assess and convert supported workloads.

Logic App Storage Inspector

Logic App Storage Inspector is a read-only Kudu site extension for examining storage used by an Azure Logic App Standard application. It supports searching workflow action and trigger history by workflow, date, or text, with results exportable as CSV or JSON. Users can browse and compare workflow-definition versions, review table and queue information, and monitor health indicators and refresh status. The extension isolates access to the current Logic App site, uses asynchronous paged operations for large storage accounts, and can be installed from Kudu Site Extensions.

News from our community

Azure Logic Apps Automation – A Practical Infrastructure Lab with Agentic Remediation

Post by João Paulo Costa

João Paulo Costa tests Azure Logic Apps Automation through an after-hours virtual-machine remediation lab. The workflow uses an agent to inspect VM metadata, tags, and runtime state, then apply guardrails before deciding whether to deallocate the resource, leave it unchanged, or request review. The article contrasts agentic decision-making with deterministic workflows, documents tool and connector choices, and examines preview limitations such as runtime-state retrieval and managed-identity support. It also emphasizes constrained permissions, explicit policies, verification after actions, and negative testing for production, exemptions, missing ownership, and disabled remediation.

Agentic Integration: Non-Deterministic Experience, Solid Core

Post by Massimo Crippa

Massimo Crippa examines whether agentic capabilities make enterprise integration non-deterministic. He separates an agent’s variable decision-making from the predictable integration layer that executes selected capabilities. The article highlights durable messaging, reliable contracts, idempotency, transactional boundaries, retries, compensation, governance, and observability as continuing requirements. It presents tools as the boundary between reasoning and execution: agents determine what should happen, while integration platforms control how operations are performed safely. Azure Logic Apps is positioned as both a deterministic integration foundation and a platform that can expose governed capabilities to emerging agentic experiences.

Build AI Agents in Azure Logic Apps (Conversational + Autonomous)

Video by Rafsan Huseynov

Rafsan Huseynov presents a video on building conversational and autonomous AI agents with Azure Logic Apps. The session describes Logic Apps as more than a background integration layer, covering orchestration, managed identities, agent loops, and the use of workflows as MCP tools. Demonstrations explore connections with Document Intelligence, Blob Storage, Microsoft Foundry, and Copilot Studio workflows, alongside conversational and autonomous agent patterns. The video also introduces a separate low-code automation experience with scoped permissions, while noting that the demonstrations use synthetic data and that the experience remains in preview.

BizTalk to Logic Apps migration (three things, everyone gets wrong)

Post by Brajesh Sinha

Brajesh Sinha explains why simple counts of BizTalk orchestrations and maps produce unreliable Logic Apps migration estimates. One orchestration can fan out into several Azure resources, supposedly simple maps may hide substantial transformation complexity, and operational requirements are often omitted from statements of work. The article highlights the architecture, mapping, and production-readiness effort that teams frequently underestimate. It encourages migration planners to assess actual behavior and dependencies rather than relying on inventory totals, helping create more realistic timelines, scope, and delivery expectations.

Hybrid Logic Apps on RKE2: a self-managed cluster with MetalLB

Post by Sonny Gillissen

Sonny Gillissen demonstrates how to run Azure Logic Apps Hybrid on a self-managed RKE2 Kubernetes cluster. Because RKE2 does not include a native load balancer, the walkthrough uses MetalLB to assign the ingress IP required by the deployment. It covers creating the cluster, configuring networking, connecting the environment to Azure Arc, and handling the platform-specific details needed for Logic Apps. The article provides a practical alternative for teams evaluating hybrid integration workloads outside managed Kubernetes services, extending earlier guidance for OpenShift environments.

An Introduction to Logic Apps Standard SDK

Video by Marcel Medina

Marcel Medina shares a Coding Night ANZ recording introducing the Logic Apps Standard SDK. The session shows how the SDK brings a modern, code-first .NET development experience to Azure Logic Apps while retaining the platform’s connectors, triggers, monitoring, and managed runtime. It is aimed at developers who want familiar tooling and stronger source-driven workflow development without giving up managed integration capabilities. The post also thanks the community for its questions and participation and provides the complete session recording for anyone who missed the live event.

Managed Identity in Logic Apps Standard: A Zero Trust Read

Post by Steef-Jan Wiggers

Steef-Jan Wiggers examines new Managed Identity support for connectors in the Logic Apps Standard local development experience. Developers can now use a consistent authentication model from development through production instead of swapping connection strings before deployment, removing a common source of unmanaged secrets. The article frames this improvement through Zero Trust while stressing that authentication alone does not replace disciplined RBAC. A working azd sample demonstrates the setup and highlights a critical application setting whose absence causes the otherwise correctly configured connection, access policy, and role assignment to fail.

Logic App Storage Inspector

Mohammed_Barqawi — Thu, 03 Sep 2026 16:28:54 GMT

Logic App Storage Inspector is a Kudu site extension for inspecting the storage used by an Azure Logic App Standard application.

Read-only: The extension only reads Logic App storage data. It does not create, update, or delete workflows, tables, queues, blobs, messages, or other storage data.

Functionality

Flow history search

Search action and trigger inputs or outputs by workflow, date, and text. Results can be copied or exported as CSV or JSON.

Flow versions

Browse workflow versions, view their JSON definitions, and compare two versions side by side and you can download the json.

Information dashboard

Review workflow table information, queue depths, health indicators, and refresh status.

Site isolation and performance

Restricts table and queue access to the current Logic App site when a storage account is shared.
Uses asynchronous, cancellable, and paged operations for large storage accounts.
Performs no write operations against the Logic App or its storage account.

Install from Kudu Site Extensions

1. Open Kudu

Open the Logic App Standard resource in the Azure portal.
Select Development Tools > Advanced Tools.
Select Go to open the Kudu/SCM site.

2. Install the extension

In Kudu, select Site extensions.
Open the Gallery tab.
Search for Logic App Storage Inspector.
Select the + button and confirm the installation.
Restart the SCM site if Kudu requests it.

3. Open the inspector

Use the extension link in Kudu, or browse directly to:

https://<logic-app-name>.scm.azurewebsites.net/logicappstorageinspector/

Access to the inspector requires permission to access the Logic App's Kudu site.

Configuration

The extension reads configuration from the Logic App environment:

Setting	Purpose
WEBSITE_SITE_NAME	Identifies the current Logic App site. Provided by App Service.
AzureWebJobsStorage	Storage connection used as a fallback.
AzureWebJobsStorage__accountName	Storage account used with managed identity.
LASI_TABLE_PREFIX	Optional explicit flow<hostId> prefix when automatic resolution is unavailable.
LASI_AUTO_REFRESH_SECONDS	Optional dashboard refresh interval.
LASI_PAGE_SIZE	Optional default history-search page size.

For managed identity, grant the Logic App identity the required Storage Table, Queue, and Blob data-reader permissions.

Source Code

the code built using GitHub copilot on VS code https://github.com/features/copilot

Repository link mbarqawi/LogicAppStorageInspector: Web-based diagnostics tool for Azure Logic Apps Standard storage, workflow history, versions, and queue health.

AI Gateway tier of Azure API Management — August 2026 updates

budzynski — Wed, 02 Sep 2026 14:26:41 GMT

The August 2026 update for the AI Gateway tier (preview) of Azure API Management introduces new capabilities for observing AI workloads and governing model spend.

Release highlights

Richer OpenTelemetry observability: AI Gateway can now emit logs, distributed traces, token metrics, and estimated cost metrics through the OpenTelemetry Protocol. The built-in monitoring experience helps teams investigate model and MCP tool activity, policy execution, latency, errors, token consumption, and individual traces.
Model cost monitoring and budget enforcement: Teams can review estimated model spend by API key and model, then use cost limit policies to set calendar-based budgets and block requests when configured limits are reached.

The release also streamlines Microsoft Foundry model imports, refines provider onboarding, improves portal reliability and error guidance, expands Anthropic Messages compatibility, and adds an in-product What's new experience.

For configuration guidance, important upgrade information, and the complete list of changes, read the full August 2026 release notes in the AI Gateway portal.

Try the latest capabilities in the AI Gateway portal.

Introducing APIOps CLI

Sreekanth_Thirthala — Tue, 01 Sep 2026 20:05:56 GMT

APIOps CLI helps teams extract, version, review, preview, and publish Azure API Management configuration through source-controlled DevOps workflows.

Today, we're excited to announce APIOps CLI, a new command-line experience designed to help organizations manage Azure API Management (APIM) using modern configuration-as-code and GitOps practices.

As APIs become increasingly central to digital transformation, organizations need a reliable way to manage API definitions, policies, products, diagnostics, and gateway configuration across multiple environments. APIOps CLI provides a streamlined, developer-friendly approach to extract, version, review, and publish API Management configuration through familiar DevOps workflows.

Why APIOps CLI?

Traditional API management processes often rely on manual configuration changes, environment-specific customizations, and limited visibility into what changed and why. As API estates grow, these approaches become difficult to scale, audit, and govern.

APIOps CLI addresses these challenges by enabling teams to manage API Management configuration as source-controlled artifacts. Every change can be reviewed through pull requests, tracked through Git history, and promoted consistently across development, test, and production environments.

The result is improved governance, greater reliability, better collaboration between API developers and platform operators, and a simpler path toward enterprise-scale API operations.

What APIOps CLI Enables

APIOps CLI provides capabilities that help organizations adopt a true APIOps model:

Extract API Management configuration into local artifact files
Store and version configuration in Git repositories
Review changes through standard pull request workflows
Publish approved artifacts back into API Management environments
Promote configuration consistently across environments
Scaffold GitHub Actions and Azure DevOps pipelines
Support automated CI/CD deployment patterns
Enable auditable, repeatable API configuration management

By treating API Management configuration as code, organizations gain the same operational excellence practices that software development teams have relied on for years.

A Modern GitOps Workflow for APIs

The APIOps CLI workflow follows a simple yet powerful pattern:

Extract configuration from an existing API Management instance.
Store the generated artifacts in source control.
Review and approve changes through pull requests.
Run automated validation and deployment pipelines.
Publish approved configuration back to target API Management environments.

This approach creates a clear separation between authoring, review, approval, and deployment while maintaining a complete audit trail of API platform changes.

For organizations already practicing GitOps, APIOps CLI integrates naturally into existing development workflows and governance processes.

Built for Real-World Enterprise Scenarios

APIOps CLI is designed to support customers operating at enterprise scale. Common use cases include:

Migrating away from manual API Management administration
Standardizing deployments across multiple environments
Establishing controlled promotion paths from development to production
Implementing governance and compliance requirements
Supporting platform engineering and API platform teams
Managing large inventories of APIs, products, policies, and configurations
Enabling self-service API development with centralized governance

Whether you're operating a single API Management instance or managing a large multi-team API platform, APIOps CLI provides a foundation for consistent and repeatable operations.

Integrated with Your Existing Toolchain

APIOps CLI works alongside the tools teams already use:

GitHub
Azure DevOps
Azure Pipelines
GitHub Actions
Azure CLI
Existing Git repositories and branching strategies

The tool can generate CI/CD scaffolding to accelerate adoption, helping teams move from manual operations to automated deployments with less effort.

Open Source and Community Driven

APIOps CLI is available as an open-source project under the Azure GitHub organization. The repository includes source code, architecture guidance, command documentation, CI/CD examples, walkthroughs, troubleshooting guidance, and reference material.

By making the project open and community-driven, we are enabling customers, partners, and contributors to participate directly in the evolution of Azure API Management DevOps practices.

Getting Started

Getting started is straightforward:

Install the APIOps CLI package.
Authenticate with Azure.
Extract an existing API Management instance into local artifacts.
Commit those artifacts to a Git repository.
Review and approve changes through pull requests.
Publish approved changes back to Azure API Management.

We recommend beginning with a non-production environment to establish your workflow, validate governance processes, and familiarize teams with the configuration-as-code model.

Looking Ahead

APIs have become a strategic asset for every organization. As API estates continue to expand, successful teams will increasingly adopt automation, governance, and GitOps practices to maintain speed without sacrificing control.

APIOps CLI is an important step in that journey. It provides a modern foundation for managing Azure API Management configurations with the same rigor, automation, and reliability that organizations expect from modern software delivery practices.

We invite you to explore APIOps CLI, try it in your environment, share feedback, and join us in shaping the future of API operations on Azure.

Resources

APIOps CLI GitHub repository: https://github.com/Azure/apiops-cli/tree/main
Microsoft Learn: Manage API Management configuration with APIOps CLI

Build governed asynchronous APIs with Azure API Management and Azure Service Bus

anishta — Mon, 31 Aug 2026 18:38:04 GMT

Many applications use Azure Service Bus to decouple services, handle traffic spikes, and process workloads asynchronously. However, securely exposing messaging capabilities to applications, partners, and internal teams can require custom middleware or messaging-specific client implementations. Today, we’re announcing the general availability of native Azure Service Bus integration in Azure API Management.

With the send-service-bus-message policy, developers can publish messages directly from an Azure API Management gateway to an Azure Service Bus queue or topic. This provides a secure and governed HTTP interface for Service Bus workloads—without requiring teams to build and operate a separate adapter service.

Connect APIs directly to Azure Service Bus

Azure API Management can act as the governed entry point for applications that submit work to Azure Service Bus.

A client sends a standard HTTP request to API Management. The gateway can authenticate and authorize the caller, validate or transform the request, and apply policies such as rate limits and quotas before publishing the message to a Service Bus queue or topic. Once the message is accepted, API Management can immediately respond to the caller while downstream services process the message asynchronously. Alternatively, message publication can be added to an existing API flow while the request continues to its primary backend. This integration brings together API governance in Azure API Management and reliable asynchronous messaging in Azure Service Bus—without adding another intermediary service.

Greater control over Service Bus messages

As part of general availability, we’re introducing additional controls for building production messaging workflows.

1. Control how messages are processed

Developers can configure the following Service Bus message properties directly in the policy:

- Message IDs to correlate messages and support duplicate-detection or idempotent processing patterns.
- Session IDs to group related messages for ordered or stateful processing.
- Time-to-live to prevent messages from being processed after they are no longer relevant.

These values can be generated dynamically using API Management policy expressions, allowing them to reflect request IDs, customer identifiers, transactions, or other application context.

2. Capture the send result

The response-variable-name attribute captures information about the Service Bus send operation in an API Management context variable.

Subsequent policies can use the result to add correlation information to an API response, emit telemetry, record an operational event, or apply conditional logic when a message cannot be sent.

3. Choose how failures affect the API

Different messaging scenarios require different failure behavior.

- When publishing the message is the primary purpose of an API, a send failure can stop policy execution and invoke the API Management error-handling path.
- When publishing is secondary—such as sending an audit event or initiating optional downstream processing—the ignore-error option can allow the primary API request to continue. Information about the send operation remains available through the response variable for logging or subsequent policy logic.

4. Secure access with managed identity

API Management authenticates to Azure Service Bus using a Microsoft Entra managed identity. Customers can use the system-assigned identity of the API Management service or specify a user-assigned managed identity. The selected identity is granted the Azure Service Bus Data Sender role for the appropriate namespace, queue, or topic. This removes the need to store Service Bus connection strings or shared access keys in API policies and makes it easier to apply least-privilege access using Azure role-based access control.

Send a message with an API Management policy

The following example sends the incoming request body to an orders queue. It assigns a message ID and expiration time, captures the result of the send operation, and treats successful publication as a required part of the API request.

<send-service-bus-message queue-name="orders" namespace="contoso-messaging.servicebus.windows.net" message-id="@(context.RequestId.ToString())" time-to-live="00:10:00" response-variable-name="serviceBusResult" ignore-error="false"> <payload> @(context.Request.Body.As<string>(preserveContent: true)) </payload> </send-service-bus-message>

A session ID can also be added when related messages need to be grouped for ordered or stateful processing. For a fully asynchronous API, the policy can be followed by return-response so that API Management acknowledges the request immediately after sending the message. For an existing API, the request can continue to its configured backend after the message is published.

Common integration scenarios

Create asynchronous APIs: Accept an order, document, or processing request through an HTTP API, publish it to a queue, and return immediately while downstream services complete the work.
Govern partner integrations: Provide partners with a managed API contract instead of exposing the underlying Service Bus namespace. API Management can authenticate callers, validate requests, and apply quotas before publishing messages.
Publish business events: Publish events to a Service Bus topic so multiple subscriptions and downstream services can process them independently.
Handle bursts of incoming traffic: Use Service Bus to buffer messages when incoming API traffic temporarily exceeds the rate at which downstream services can process requests.
Add events to existing API operations: Publish audit, notification, analytics, or workflow events while allowing the primary API request to continue to its configured backend.
Preserve workflow affinity: Use Service Bus sessions to group related messages for ordered or stateful processing based on a customer, transaction, order, or workflow identifier.

Get started

To send messages from Azure API Management to Azure Service Bus:

Create or select an Azure Service Bus queue or topic.
Enable a system-assigned or user-assigned managed identity on the API Management service.
Assign the identity the Azure Service Bus Data Sender role.
Add the send-service-bus-message policy to an API operation.
Configure the message payload, processing properties, output variable, and failure behavior.

With native Azure Service Bus integration, Azure API Management provides a secure and governed way to connect HTTP APIs with asynchronous messaging workloads—without requiring additional middleware.

Learn more

BizTalk Server 2020 End-of-Sale Announcement

hcamposu — Mon, 31 Aug 2026 09:00:00 GMT

Executive Summary:

BizTalk Server 2020 is the final release of BizTalk Server, and Microsoft expects sales of BizTalk Server 2020 and Host Integration Server 2020 to end March 31, 2027. Mainstream support for BizTalk Server 2020 continues through April 12, 2028, after which the product remains subject to Microsoft’s Fixed Lifecycle Policy. Microsoft also plans to offer eligible customers an optional, paid extended-mainstream support offering through April 10, 2030. Customers should begin planning their migration to Azure Logic Apps Standard or Azure Logic Apps Hybrid now, based on their deployment requirements.

Closing a chapter

Microsoft currently expects sales of BizTalk Server 2020 and Host Integration Server 2020 to end on March 31, 2027. Customers with existing valid licenses may continue to deploy and use the software in accordance with their licensing terms. Mainstream support for BizTalk Server 2020 continues through April 12, 2028. The end-of-sale date does not require customers to stop running licensed deployments, but customers should begin migration and licensing planning now because the extended-mainstream support offering described below remains subject to final eligibility, coverage, pricing, and purchasing terms.

Microsoft plans to offer eligible BizTalk Server 2020 customers a paid, time-limited extended-mainstream support option from April 13, 2028, through April 10, 2030. The offering is intended to provide additional migration time, will have narrower coverage than the original mainstream-support phase, and will not add new product features. Eligibility, availability, supported components, servicing commitments, purchasing terms, and the official offering name will be published before enrollment opens.

If you need to buy BizTalk Server 2020, or Host Integration Server 2020, you can do it until March 31, 2027.

Recommended action

Begin migrating your BizTalk Server workloads now, selecting Azure Logic Apps Standard or Azure Logic Apps Hybrid according to your organization’s hosting, networking, latency, data-residency, and operational requirements. Treat additional support coverage as contingency time rather than the default destination. Starting early gives teams time to inventory dependencies, redesign excluded capabilities, validate migrated solutions, and make commercial decisions before mainstream support ends. The Logic Apps Migration Agent can accelerate assessment and planning, convert supported artifacts, and assist with validation and deployment of refactored solutions on Azure Logic Apps Standard or Azure Logic Apps Hybrid.

Extended-mainstream support scope

Paid extended-mainstream support is planned as an optional, temporary bridge for eligible customers completing their migration. It is separate from the Extended Support phase available under Microsoft’s Fixed Lifecycle Policy and is expected to provide a different, narrower scope than the original mainstream-support phase. Microsoft expects the paid offering to run from April 13, 2028, through April 10, 2030. Certain BizTalk Server capabilities are expected to be excluded from the paid offering; the following list identifies the currently expected exclusions.

Business Activity Monitoring (BAM) — The framework and tooling for capturing, tracking, and presenting near real-time business milestones, KPIs, and operational data from running BizTalk processes. Servicing, fixes, and updates for BAM components will not be provided under extended support.
Enterprise Service Bus Toolkit (ESB Toolkit) — The libraries, itinerary services, and patterns that extend BizTalk with dynamic, itinerary-based routing, transformation, and centralized exception handling for service-oriented solutions. The ESB Toolkit will not receive servicing or support under extended support.
Industry accelerators (SWIFT, HL7, and RosettaNet) — The domain-specific accelerators that provide schemas, pipelines, and validation for financial (SWIFT), healthcare (HL7), and supply-chain (RosettaNet) messaging standards. These accelerators will not receive servicing, schema updates, or support under extended support.
Legacy enterprise adapters — The adapters that connect BizTalk to line-of-business and enterprise applications such as Siebel, PeopleSoft, TIBCO, and JD Edwards. These adapters will not receive servicing or support under extended support.
Application Lifecycle Management (ALM) tooling and integrations — The BizTalk-specific tooling and integrations used for source control, automated build, deployment, and testing of BizTalk applications. These BizTalk-specific ALM components will not receive servicing or support under extended support.
BizTalk Server images in Azure Marketplace — Microsoft currently expects to deprecate the BizTalk Server virtual-machine offer in Azure Marketplace. This affects the future availability of the Marketplace deployment image; it does not, by itself, make an otherwise eligible existing BizTalk Server 2020 deployment ineligible for paid extended-mainstream support. Microsoft will publish the effective date and guidance for existing virtual machines, new or replacement deployments, scaling, disaster recovery, customer-managed images, licensing, billing, patching, and support.
New Visual Studio version support — Compatibility with Visual Studio versions newer than Visual Studio 2022 will not be added under extended support. Customers should review the Visual Studio 2022 lifecycle and support offering separately, because its coverage terms are independent of BizTalk Server extended support.

Customers that depend on an excluded capability should prioritize the affected workloads in their migration plan. Use the Logic Apps Migration Agent to assess dependencies, inform target-architecture decisions, convert supported artifacts, and validate the migrated solution. Excluded BizTalk capabilities may require architectural redesign or manual implementation outside the agent.

Customers are not required to purchase paid extended-mainstream support. Customers that do not enroll remain subject to Microsoft’s Fixed Lifecycle Policy and the applicable BizTalk Server 2020 lifecycle dates. The availability of technical support, non-security updates, security updates, and other services during the standard Extended Support phase depends on the policy requirements and the customer’s applicable support arrangement. The paid extended-mainstream support offering described here is an optional, separate offering for eligible customers that require additional coverage while completing their migration.

After the end-of-sale date, customers that already hold valid BizTalk Server 2020 licenses may continue to deploy and use the software in accordance with the applicable licensing terms.

Eligibility

Paid extended mainstream support will be available to eligible customers with properly licensed BizTalk Server 2020 deployments. The final eligibility requirements will be provided in the published offering terms.

Eligible products and versions: Paid extended-mainstream support is expected to be available for eligible deployments of BizTalk Server 2020 Enterprise, Standard, or Branch editions. Customers using Host Integration Server 2020 may also purchase the BizTalk Server paid extended-mainstream support offering to receive the applicable extended mainstream-support coverage for their HIS 2020 deployments, including customers that acquired BizTalk Server licences primarily to obtain HIS usage rights. BizTalk Server 2016, HIS 2016, and earlier versions will not be eligible.
Azure Marketplace deployments: Existing BizTalk Server 2020 deployments created from eligible Azure Marketplace images are expected to qualify for paid extended-mainstream support, subject to the final offering terms. Customers must meet the applicable licensing, Software Assurance, supported-configuration, and complete-deployment coverage requirements. Microsoft will clarify how eligibility, licensed-core quantities, pricing, and purchasing apply when BizTalk Server software charges are included in the Azure Marketplace virtual-machine rate rather than acquired through a separate BizTalk Server licence agreement.
Valid licenses: Customers are expected to maintain sufficient BizTalk Server licenses for each covered deployment in accordance with the applicable licensing model, including relevant core minimums, licensing of physical or virtual environments, and license-reassignment rules. Final extended-support licensing requirements will be stated in the published offering terms.
Software Assurance: Active Software Assurance will be required at enrollment and throughout the applicable coverage period.
Complete deployment coverage: Extended mainstream support must be purchased for all licensed cores in each enrolled deployment. Partial coverage of an enrolled production environment will not be permitted.
Supported configuration: Covered environments must remain on a supported BizTalk Server 2020 configuration and meet published requirements for cumulative updates, operating systems, databases, and dependent components.
Annual validation: Eligibility and licensed-core quantities will be confirmed for each coverage year. Customers must remain eligible to purchase Year 2 coverage.

As part of the eligibility review, Microsoft may request licensing records, deployment inventories, configuration details, and migration-plan information. Complete requirements and enrollment instructions will be published before the offering becomes available.

Purchasing details

Paid extended mainstream support will be offered as annual coverage based on the licensed cores in each enrolled BizTalk Server 2020 deployment. Microsoft will publish final pricing, availability, enrollment dates, purchasing channels, and transaction terms before sales begin.

Purchasing paid extended-mainstream support is optional and is not required for BizTalk Server 2020 to follow the Fixed Lifecycle Policy.

Host Integration Server 2020: Eligible HIS 2020 customers will purchase coverage through the BizTalk Server paid extended-mainstream support offering. Customers that do not require HIS IBM Systems Network Architecture (SNA) capabilities should also evaluate Azure Logic Apps Standard or Azure Logic Apps Hybrid as a modernization alternative before purchasing additional support coverage. Azure Logic Apps Standard does not support SNA; customers that depend on HIS 2020 SNA capabilities must transition to Host Integration Server 2028.
Coverage periods: Year 1 is expected to begin the next day mainstream support ends, on April 13, 2028, and continue through April 13, 2029. Year 2 is expected to run from April 14, 2029, through April 10, 2030. The final offering terms will confirm whether the boundary dates are inclusive and will specify the exact enrollment and coverage periods.
Purchase sequence: Microsoft expects customers to purchase Year 1 coverage by April 11, 2028, to remain eligible to purchase Year 2 coverage. The final enrollment deadline and Year 2 eligibility conditions will be specified in the published offering terms.
Price: Microsoft expects annual extended-mainstream support pricing to be 100% of the applicable BizTalk Server license cost under the customer's licensing agreement. Extended mainstream support is expected to be offered as an annual add-on for eligible BizTalk Server licenses. Final pricing and costs may vary by licensing agreement, geography, currency, available discounts, and the published offering terms.
How to purchase: Customers will purchase coverage through an authorized Microsoft commercial licensing channel with support from their Microsoft account team or licensing partner.
Separate support services: The annual extended-mainstream support fee is expected to cover only the servicing and support rights defined in the final offering terms. It will not include unlimited incident support, advisory services, migration delivery, solution implementation, or other professional services; customers may need a separate support plan or services agreement for those needs.
Annual purchase: Coverage will not renew automatically. Customers must place a separate order and complete an eligibility review for each year. Support beyond April 10, 2030, is not planned.

Contact your Microsoft account team or licensing partner to review eligible deployments, confirm licensed-core quantities, and obtain a quote when the offering becomes available.

Discounts and incentives

Microsoft plans to offer a targeted incentive for eligible existing BizTalk Server customers that are actively migrating to Azure Logic Apps Standard or Azure Logic Apps Hybrid. The incentive is designed to reduce near-term migration costs and support a faster move to the selected Logic Apps deployment model. It will not be automatic or broadly available; eligibility, approval, and final commercial terms must be confirmed by the customer’s Microsoft account team.

Timing and important conditions

Who can qualify: The incentive is intended exclusively for existing BizTalk Server 2020 customers approaching the announced BizTalk Server lifecycle milestones and actively migrating workloads to Azure Logic Apps Standard or Azure Logic Apps Hybrid.
Redemption period: The incentive is expected to become available on August 31, 2026, and remain available through April 12, 2028, subject to publication of the program terms, eligibility approval, continued availability, and any applicable funding limits.
Discount duration: The approved discount is expected to apply during the customer’s first qualifying Enterprise Agreement term after approval. The published program terms will define the eligible agreement types, qualifying start date, covered Azure services, discount duration, and treatment of renewals or agreement changes.
Qualification: The incentive is subject to eligibility review and approval.

Recommended action

Ask your Microsoft account team or licensing partner to assess your migration scope, confirm which eligible migration path applies, and request consideration for the incentive.

Migration support

Contact your Microsoft account team to determine whether your organization is eligible for migration assistance delivered by the Azure Logic Apps product group or through another available migration-factory program. Program names, eligibility criteria, engagement scope, and availability will be confirmed through your account team.

Migration options for Host Integration Server workloads

Customers using Host Integration Server 2020 for application, data, messaging, or terminal integration—and who do not depend on HIS SNA capabilities—should evaluate Azure Logic Apps Standard or Azure Logic Apps Hybrid as a modernization target. Azure Logic Apps provides mainframe and midrange integration capabilities for scenarios involving IBM CICS, IMS, IBM i programs, DB2, IBM MQ, host files, and 3270 applications. Customers should assess each workload against the available connectors, supported protocols, networking, security, and operational requirements. Azure Logic Apps Standard does not support SNA. Customers running HIS 2020 workloads that depend on SNA capabilities must plan to transition to Host Integration Server 2028.

Key dates

March 31, 2027: Sales of BizTalk Server 2020 and Host Integration Server 2020 are expected to end.
April 12, 2028: Mainstream support for BizTalk Server 2020 ends.
April 13, 2028: BizTalk Server 2020 enters the Extended Support phase under Microsoft’s Fixed Lifecycle Policy, subject to the applicable policy requirements and lifecycle dates.
April 13, 2028–April 10, 2030: Planned paid extended-mainstream support period for eligible BizTalk Server 2020 customers, subject to the final published offering terms.
September 30, 2027: Host Integration Server 2028 is planned for release as a standalone product. Release timing is subject to change.
July 7, 2030: Extended Support for Host Integration Server 2020 is currently scheduled to end. This date is separate from the planned BizTalk Server 2020 paid extended mainstream support period, which is expected to end April 10, 2030.

Start your modernization journey with the Logic Apps Migration Agent. Use the agent to inventory and assess your BizTalk applications, prioritize integrations, build a phased migration plan, convert supported artifacts and workflows, and support validation, testing, and deployment to Azure Logic Apps Standard or Azure Logic Apps Hybrid. Excluded or unsupported BizTalk capabilities may require architectural redesign or manual implementation outside the agent. The agent’s AI-assisted, human-in-the-loop approach can accelerate modernization while your teams retain control of architecture and implementation decisions. Contact your Microsoft account team to discuss migration-assistance eligibility and commercial options.

Learn more: BizTalk Server product lifecycle update | Bringing all your integration workloads to Logic Apps Standard | Fixed Lifecycle Policy – Extended Support

Zonal redundancy in API management Standard v2

Sreekanth_Thirthala — Thu, 27 Aug 2026 20:57:25 GMT

APIs are the backbone of modern applications, powering everything from mobile experiences and microservices to AI-driven applications and business-critical integrations. As customers continue to modernize their platforms on Azure, they increasingly expect their API infrastructure to remain available even in the face of datacenter-level disruptions.

With zone redundancy in Standard v2, Azure API Management now enables customers to increase resilience against Availability Zone failures while continuing to benefit from the simplicity, performance, and cost efficiency of the v2 platform.

Why Zone Redundancy Matters

Azure Availability Zones are physically separate locations within an Azure region, each with independent power, cooling, and networking infrastructure. By distributing API Management resources across multiple zones, organizations can reduce the impact of a single datacenter failure and improve service continuity for their APIs.

Until now, customers who required built-in zone-level resiliency often needed to evaluate higher-end deployment options. With this enhancement, Standard v2 customers can now deploy API gateways across Availability Zones and benefit from improved reliability while maintaining the streamlined operational model of the v2 platform.

What’s New

Zone Redundancy for Standard v2 extends the platform's resiliency by distributing service capacity across multiple Availability Zones within a supported Azure region.

Key benefits include:

Higher Availability: API traffic continues to flow even if a single Availability Zone experiences an outage.
Built-in Resiliency: Redundancy is provided at the platform layer, reducing the need for customers to design and manage complex intra-region failover solutions.
Production-Ready Reliability: Customers can confidently run critical API workloads on Standard v2 with stronger availability guarantees.
Operational Simplicity: The service automatically manages capacity distribution, health monitoring, and recovery behavior across zones.
Cost-Effective Resilience: Customers gain zone-level protection without requiring an enterprise-tier deployment model.

Built on the Modern v2 Platform

The v2 platform was designed from the ground up to provide a faster, more reliable, and more scalable API Management experience. Standard v2 already delivers capabilities such as rapid deployment, simplified networking, workspace support, and flexible scaling. Zone Redundancy further strengthens the platform by expanding its reliability story for production workloads.

This announcement builds on our broader investment in making Azure API Management more accessible to a wider range of organizations, from digital-native startups to large enterprises modernizing their application estates.

Ideal Scenarios

Zone Redundancy in Standard v2 is particularly valuable for customers who:

Run business-critical APIs that must remain available during datacenter incidents.
Consolidate multiple application workloads behind a single API gateway.
Expose APIs consumed by mobile, partner, and customer-facing applications.
Support AI applications and agent-based architectures that depend on highly available API endpoints.

For organizations adopting modern cloud and AI native architectures, this capability helps ensure that API infrastructure remains aligned with broader application resiliency strategies.

A Foundation for Reliable AI and API Platforms

As AI-powered applications continue to proliferate, APIs increasingly become the critical connection layer between models, agents, business systems, and data platforms. Downtime at the API layer can have a direct impact on application availability, customer experience, and business operations.

By bringing zone redundancy to Standard v2, we are making it easier for organizations to build highly resilient API platforms that can serve as the foundation for next-generation AI and digital transformation initiatives.

Getting Started

Zone Redundancy for Standard v2 can be enabled in supported Azure regions, allowing customers to deploy API Management with built-in protection against Availability Zone failures.

We recommend reviewing your application's overall resiliency architecture, including backend redundancy, traffic management, and disaster recovery requirements, to maximize the benefits of zone-resilient API infrastructure.

Enable Zone Redundancy in the Azure Portal

Getting started with Zone Redundancy in Azure API Management Standard v2 is straightforward and can be configured during service creation.

Create a New Standard v2 Instance with Zone Redundancy

Sign in to the Azure portal.
Select Create a Resource and search for Azure API Management.
Choose Standard v2 as the service tier.
Select a region that supports Availability Zones.
In the Availability Zones section, enable Zone Redundancy.
Review and create the service.

After deployment, Azure API Management automatically distributes service capacity across multiple Availability Zones within the selected region, helping maintain API availability during a zone-level outage.

Looking Ahead

This release represents another step in our ongoing investment in the Azure API Management v2 platform. We remain committed to delivering the reliability, scalability, security, and developer experiences that organizations expect from a modern API management service.

We are excited to see what our customers build with a more resilient Standard v2 platform and look forward to your feedback as you continue modernizing and scaling your API ecosystems on Azure.

Learn more by visiting the Azure API Management documentation and exploring the latest reliability guidance for API Management deployments.

Give your Copilot agents real tools, without hand-wiring MCP

WSilveira — Thu, 20 Aug 2026 18:08:19 GMT

You’re running agents in the GitHub Copilot app - maybe three at once, each on its own branch, each working a task while you steer. It’s a good way to work, right up until an agent needs to reach outside your repo.

It needs to read a SharePoint library, file a Salesforce record, or check an Outlook calendar, and suddenly it’s blind. An agent is only as capable as the tools you hand it.

The usual way to hand it one of those tools is to wire up a Model Context Protocol (MCP) server by hand: find the endpoint, paste it into config, add an auth header, keep the token alive, and hope you got the casing right. Then your teammate does the same thing on their machine, and the next person after that.

The MCP Connectors canvas removes the hand-wiring. It’s a plugin for the GitHub Copilot app: it lists the hosted MCP servers already published in your Azure Connector Namespace, and you connect one to Copilot by selecting it - no URL, no header, no local proxy.

Where the servers come from

Connector Namespace is the managed Azure service on the other end. It provides a list of curated MCP Servers that you can use to quickly create and manage MCPs connections. It also does the work you’d rather not: it stores and rotates the credentials, applies retry and throttling policies, and scales the server. Your machine never holds a raw secret related to the end systems that MCP touches, and access is governed by access policies, allowing fine grained control on who can use the MCP servers.

So, when you connect a server from the canvas, you’re not standing up infrastructure. The server already exists, already authenticated, already managed. You’re pointing Copilot at it.

Prerequisites

GitHub Copilot app with canvas extension support.
An Azure subscription with permission to cerate and view the namespace and to create connections and hosted managed MCP server configurations.
Connector Namespace is in preview, and availability varies by region.

Install

From the GitHub Copilot app, add the following prompt.

Install connector-namespaces v1.2.0 for my user account, reload it, verify it is running, then open the MCP Connectors canvas.

Open the Connector Namespace canvas in a new session

Once you install if you need to open the Connector Namespace in a new session, just request it in a prompt:

Open the MCP Connectors canvas.

Connect an MCP server

Open the MCP Connectors canvas.
Select Sign in to Azure, then choose a subscription and Connector Namespace.
Browse or search the MCP servers grouped under Microsoft and Partners.
Select Connect and complete the connector’s separate authentication or consent flow.
Confirm the server appears under My MCPs.
Restart GitHub Copilot so a new session loads the added tools.

ℹ️Note
That last step matters more than it look. Copilot loads an agent’s tools when a session starts, so a server you add mid-session shows up in the next one, not the one you’re in.

Manage connected servers

My MCPs shows the servers connected to Copilot.

Sandbox opens a connected server in the Connector Namespace playground, so you can try a tool call yourself before you let an agent lean on it.

Disconnect removes the MCP registration from your MCP configuration. The MCP is still available in Connector namespace to be added again later. Also if you are sharing the connector namespace with other developers, this only remove the your local configuration.

Connect adds configured MCP connectors that are not registered locally yet to your local MCP configuration.

Delete from namespace… removes the MCP registration from your MCP configuration and deletes the MCP connection from your connector namespace. If you are sharing the connector namespace with other developers this will affect any developer using this MCP connector – be careful when using this.

Switch namespace switches the active subscription or namespace - useful when you keep dev and production connections apart.

How it works and security

The extension registers each server directly in Copilot’s user-scoped MCP configuration. There’s no local MCP proxy sitting in the tool path between the agent and the server.

The canvas itself runs on loopback. Your Azure tokens stay in process memory, the selected namespace coordinates may be cached locally, and gateway credentials are sent only to the server’s configured HTTPS endpoints. The connector’s own secrets never reach your machine. That’s the namespace’s job, which is also why an admin can rotate or revoke a connection in one place instead of chasing down every developer’s config.

Where can I use my connected MCP servers

You manage the servers from the canvas, but they don’t only work there. The canvas writes to Copilot’s user-scoped MCP configuration at ~/.copilot/mcp-config.json, and the GitHub Copilot app is built on GitHub Copilot CLI. Connect a server once and it’s available to both.

Agent sessions in the app. Any session on your machine picks the server up, whatever repository or branch it’s working on, because the config is user-scoped rather than per-project.

Copilot CLI. The same server shows up in the terminal. Run copilot mcp list to confirm it, or /mcp show SERVER-NAME in an interactive session to see the tools it exposes.

Two things to know:

Tools load when a session starts, so connect first and start the session second.
A project-level .mcp.json or .github/mcp.json takes precedence over your user config when the names collide, which is what you want if a repository pins its own version of a server.

VS Code is the exception. Copilot Chat there reads .vscode/mcp.json, a separate file the CLI doesn’t use, so a server you connect in the canvas won’t appear in VS Code until you configure it there too.

Where this all sits today

The GitHub Copilot app went generally available in June 2026, and canvases shipped with it, so neither is a preview feature. The MCP Connectors canvas is a published extension you install at personal scope. You get the version we ship and tested, not one an agent generates on the fly from a prompt.

Two caveats. GitHub doesn't publish a compatibility guarantee for the canvas extension format, so an app update may need a matching update from us. Re-run the install commands above to pick it up if you see any issues. On the Azure side, Connector Namespace is still in preview. Check the documentation for more details on this service outside the GitHub Copilot App support.
If you're on Copilot Business or Enterprise, check with your admin that the GitHub Copilot app policy is enabled. It's on by default, and it's separate from the Copilot CLI policy.

Try it

Install the plugin, point it at a namespace, and connect one server your agents keep reaching for: the SharePoint library, the CRM, whatever it is. Then watch an agent actually use it in the next session. Tell me where the canvas saved you a config headache and where it got in your way. That’s the feedback we act on before general availability.

Power Azure SRE Agent with the tools it needs

lily-ma — Tue, 18 Aug 2026 20:36:37 GMT

What is the Azure SRE Agent

Azure SRE Agent is an AI-powered service designed to reduce operational toil. Teams can use it to:

Investigate incidents and identify probable causes.
Automate health checks, compliance reviews, and other scheduled work.
Answer questions such as “What changed before this service became degraded?”
Propose remediations while allowing teams to require human approval.

An effective investigation rarely depends on one source of information. An alert might originate in Azure Monitor, while deployment history lives in source control, telemetry stored in another observability platform, and incident records in a service-management tool. Without access to those systems, you must retrieve and transfer the information manually, adding context switching and slowing diagnosis.

MCP servers can give SRE Agent tools to query telemetry, inspect deployments, retrieve database records, look up incidents, etc. SRE Agent provides native connection for some servers such as GitHub, Datadog, New Relic, and Splunk. Connector Namespace makes it easier to host additional remote MCP servers you want the agent to use.

Removing remote MCP server hosting burden

Connecting SRE Agent to an existing remote endpoint is straightforward. Hosting that endpoint yourself is not.

You must deploy the server, provide secure HTTPS infrastructure, configure authentication, manage downstream credentials, scale the runtime, monitor its health, recover failed instances, and maintain it over time. These responsibilities are necessary, but the value is in the server’s tools not in operating another service.

Azure Connector Namespace is a fully managed service for hosting connectors and MCP servers. You select the server you need and let the namespace handles the operational and maintenance tasks. The offering is currently in preview. See documentation for supported regions and other preview considerations.

You’ll find a wide variety of servers in the Connector Namespace’s catalog. Some examples of useful servers for the SRE agent include:

Database servers such as Azure SQL and Azure Cosmos DB
Source control and CI/CD servers like GitLab
Incident management servers like Jira and PagerDuty

A note on what's currently in development: We're building “bring-your-own” server support, allowing you to supply your own server image while the namespace handles hosting and operations. Please keep an eye out for the blog post about this!

Deploy server and connect it to SRE Agent

The following example deploys the SQL MCP server in Connector Namespace and connects it to Azure SRE Agent.

1. Server deployment

Prerequisite: Install the Azure Developer CLI (azd).

Clone the sql-server-samples repo:

git clone https://github.com/microsoft/sql-server-samples.git

Navigate to the azure-sql-mcp sample

cd sql-server-samples/samples/applications/azure-sql-mcp

From the azure-sql-mcp folder, run the following to log into your Azure subscription and then deploy the server and related resources:

azd auth login azd up

The last command will prompt for the following before deployment:

Prompt	Suggested value	Explanation
Enter a unique environment name	mcp-dev	This name added as prefix to Azure resources created
Select an Azure Subscription	Pick your subscription	Resources will deploy under this subscription
Enter value for connectorNamespaceIdentityType	UserAssigned	User assigned identity is recommended as it’s not tied to resource lifecycle
Enter value for deployerLoginName	Enter your Azure subscription login email	To give your identity access to the MCP server
Enter value for the location	Pick a supported region	Supported regions: West Central US, Central US, East Asia, North Europe

Once deployment finishes, copy the MCP endpoint for use later. It looks similar to:

https://<app-name>.<region>.logic.azure.com/api/connectorGateways/123abc456defg7890/mcpServerConfigs/sql-mcp/mcp

(Optional) Test deployed server in Visual Studio Code GitHub Copilot: Open command palette > search MCP: Add server > pick HTTP > enter MCP endpoint and server name > pick Local Workspace. Inside .vscode/mcp.json, click Start above server name, then allow authentication with Microsoft in the popup and log into Azure subscription account.

2. Configure MCP connector in SRE Agent

Connector Namespace does not create the connection in SRE Agent. Add the server endpoint through SRE Agent’s existing MCP connection experience.

Open the Azure SRE Agent portal
On the left menu, go to Builder > Connectors, and select + Add connector
Under Choose a connector, select the MCP tab, choose MCP server, and select Next
Configure the connector:

Field	Value
Name	A descriptive name for the server
Connection type	Streamable-HTTP
URI	The hosted server endpoint from Connector Namespace
Authentication method	Managed identity (Selecting managed identity automatically creates an identity for the connector.)
Azure AD token scope	https://apihub.azure.com/.default

Select Next. Before testing the connection, grant the managed identity access to the MCP server.

3. Authorize the managed identity

Open the Azure portal, search for the managed identity by name.
In the identity’s Overview page, click JSON View (top right) and copy the tenantId and principalId. The principal ID is also called the object ID.
Open Connector Namespace portal and search for the deployed namespace.
Inside the namespace, navigate to the MCP Connectors tab on the left, then select the SQL MCP server.
Inside the MCP server, click Access Policies, then select Add Access Policy.
Enter the tenant ID and principal ID, then select Create.

4. Test and finish the connection

Return to Azure SRE Agent portal and select Test connection.
After the test succeeds, select the server tools the agent should use.
Select Add connector.

Establishing the connection can take a minute. Select Refresh at the top of the connectors page until its status changes to Connected.

The agent can now use the selected server tools in chat threads. The azd deployment from previous created and seeded a SQL database with sample blog post data, so you can ask something like:

What are the top blog posts?

For more details, see MCP connectors and tools in Azure SRE Agent.

Focus on the server, not its infrastructure

MCP servers can give Azure SRE Agent access to the additional systems it needs to investigate incidents and perform operational work effectively. However, operating every remote server yourself introduces infrastructure, security, and maintenance responsibilities that distract from that goal.

Connector Namespace removes much of that friction. Your primary question becomes “Which MCP server do I want to host?” rather than “How will I deploy, secure, scale, monitor, and maintain it?”

Once deployed, the hosted endpoint can be added to Azure SRE Agent through its existing MCP connection experience. That gives teams a straightforward path to extending the agent with more operational tools, without turning MCP server hosting into another platform they must build and run.

Try Connector Namespace with Azure SRE Agent and share your feedback!