Azure Integration Services Blog articles

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

anandgmenon — Thu, 23 Jul 2026 05:53:29 GMT

Azure Logic Apps Hybrid lets you run the Logic Apps runtime on your own Kubernetes cluster and still author, deploy, and monitor from Azure. The previous post walked through Red Hat OpenShift. This one is RKE2. We spun up a single-node RKE2 cluster, gave the ingress an IP with MetalLB, connected it to Arc, and shipped a Hybrid Logic App end-to-end. A handful of things needed care along the way, and those are what this post is really about.

If you've done Hybrid on AKS or K3s, the shape will look familiar. The official requirements doc covers the general flow. RKE2 is close enough to vanilla Kubernetes that most of it just works out of the box. Four things don't. Three of them are DNS. They're called out at the step they matter.

What makes RKE2 different?

Area	What we found
Ingress IP	RKE2 has an embedded cloud-controller-manager for node lifecycle, but no service load balancer. `type: LoadBalancer` sits at `<pending>` until you bring one. We used MetalLB (Step 2).
Pod security	No SCC dance like OpenShift; the extension pods schedule as-is. What we did hit was the node's `inotify` limit. Enough runtime pods use it that the default runs out and about half the deployment crash-loops (Step 4).
CoreDNS	RKE2 names its DNS objects `rke2-coredns-rke2-coredns`, not `coredns`/`kube-dns`. `az containerapp arc setup-core-dns` doesn't have an RKE2 distro flag yet, so DNS is manual (Step 7).
Distribution flag	RKE2 is upstream Kubernetes. Don't copy the OpenShift install command; the `Azure.Cluster.Distribution=openshift` and `coreDNSVersion` overrides don't apply here and will bite you (Step 4).

Prerequisites

A Linux host	Anywhere RKE2 runs: bare metal, a VM, an edge appliance. We used a single Ubuntu 22.04 Azure VM (`Standard_D8as_v5`) so everything was easy to nuke afterwards. 4 vCPU / 16 GB is the practical floor.
Azure subscription	Rights to create Arc resources, custom locations, and connected environments.
Azure CLI	Latest, with the `connectedk8s`, `k8s-extension`, `customlocation`, and `containerapp` extensions.
An SMB file share	Reachable from the cluster, for workflow artifacts.
A spare IP range	A small unused range on your node's L2 network for MetalLB to hand out (Step 2).

az extension add --name connectedk8s
az extension add --name k8s-extension
az extension add --name customlocation
az extension add --name containerapp

Step 1: Stand up RKE2

One line and a couple of minutes:

curl -sfL https://get.rke2.io | sudo sh -
sudo systemctl enable --now rke2-server.service

# kubectl + kubeconfig are dropped in place
export PATH=$PATH:/var/lib/rancher/rke2/bin
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
kubectl get nodes          # Ready in ~2-5 min after the first image pull

RKE2 servers are schedulable by default, so this single node is your entire cluster. No taint to remove. If you want to run kubectl from your laptop, add the node's public IP or hostname to tls-san in /etc/rancher/rke2/config.yaml before the first start, then copy rke2.yaml out and swap 127.0.0.1 for that address.

Quick sanity check. Expose a throwaway nginx as LoadBalancer: kubectl create deploy nginx --image=nginx && kubectl expose deploy nginx --port=80 --type=LoadBalancer. The EXTERNAL-IP will sit at <pending> forever. That's the gap MetalLB fills in the next step. Clean up the deployment and service when you're done looking.

Step 2: Give the ingress an IP with MetalLB

All the Logic Apps in this environment share a single Envoy ingress, and something has to give that service an IP. A cloud does it for you; on-prem, you pick one of two options:

In-cluster load balancer. MetalLB (or Cilium, kube-vip, OpenELB) assigns an IP from a pool on your node network. Leave envoy.serviceType=LoadBalancer in Step 4. This is what we did.
External L4 load balancer in front of NodePort. If you already run an F5, HAProxy, NetScaler, or an Azure Standard Load Balancer, keep using it. Set envoy.serviceType=NodePort (plus envoy.nodeHttpsPort / envoy.nodeHttpPort) and point your LB at those NodePorts. Then pass the LB's VIP as --static-ip in Step 6.

We went with MetalLB in L2 mode:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.9/config/manifests/metallb-native.yaml
kubectl wait --for=condition=Ready pods --all -n metallb-system --timeout=180s

Then give it a pool from your node subnet and advertise it over L2:

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: hybrid-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.240-192.168.1.250   # a spare range on your node network
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: hybrid-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - hybrid-pool

Two things to watch. The range should be free on your node subnet, and it must not collide with RKE2's cluster (10.42.0.0/16) or service (10.43.0.0/16) CIDRs. Re-run the throwaway LoadBalancer test from Step 1; the EXTERNAL-IP should now be one of your pool addresses.

Running MetalLB on one cloud VM? L2 mode ARPs the pool IPs on the node's network, but a cloud SDN won't route an unassigned IP to your NIC from the outside. It works fine for anything inside the cluster (kube-proxy programs the IP locally), but to hit envoy from outside the VM you'll need to socat-forward the VM's public IP to the LB IP, or add the pool IP as a secondary ipconfig on the NIC. On real on-prem L2 you don't have to think about any of this.

Step 3: Connect the cluster to Azure Arc

az connectedk8s connect --name <cluster> --resource-group <rg> --location <region>
kubectl get pods -n azure-arc      # all agents Running in a couple of minutes

If your host is behind a strict egress policy, or in our case an internal MS VM with an inbound-deny NRMS policy, remember that Arc onboarding only needs outbound connectivity and a local kubeconfig. We ran the connect command on the VM itself using a system-assigned managed identity (az login --identity). No inbound port, no browser device-code prompt.

Step 4: Install the Container Apps extension

This is the extension that turns the cluster into a Logic Apps host. On RKE2 it's the plain command, with no Azure.Cluster.Distribution or coreDNSVersion overrides. If you copy those from an OpenShift guide, the install will still succeed and then behave in mildly confusing ways.

az k8s-extension create \
  --resource-group <rg> --cluster-name <cluster> \
  --cluster-type connectedClusters --name logicapps-aca-extension \
  --extension-type Microsoft.App.Environment \
  --release-train stable --auto-upgrade-minor-version true --scope cluster \
  --release-namespace logicapps-aca-ns \
  --configuration-settings "Microsoft.CustomLocation.ServiceAccount=default" \
  --configuration-settings "appsNamespace=logicapps-aca-ns" \
  --configuration-settings "clusterName=<env-name>" \
  --configuration-settings "keda.enabled=true" \
  --configuration-settings "keda.logicAppsScaler.enabled=true" \
  --configuration-settings "keda.logicAppsScaler.replicaCount=1" \
  --configuration-settings "containerAppController.api.functionsServerEnabled=true" \
  --configuration-settings "functionsProxyApiConfig.enabled=true" \
  --configuration-settings "envoy.serviceType=LoadBalancer"

Our first install came back "Succeeded", but half the pods were in CrashLoopBackOff. billing, containerapp-controller, keda-logicapps-scaler, mdm, and log-processor all had the same line in their logs:

The configured user limit (128) on the number of inotify instances has been reached

These are .NET services with FileSystemWatcher under the hood. The default fs.inotify.max_user_instances=128 on stock Ubuntu is comfortably below what the extension needs. Raise it on the node, delete the pods, done:

sudo sysctl -w fs.inotify.max_user_instances=8192
sudo sysctl -w fs.inotify.max_user_watches=1048576
echo -e "fs.inotify.max_user_instances=8192\nfs.inotify.max_user_watches=1048576" | sudo tee /etc/sysctl.d/99-inotify.conf
kubectl delete pods --all -n logicapps-aca-ns

After that everything came up green, and envoy grabbed a MetalLB address on its own. Confirm:

az k8s-extension show -g <rg> --cluster-name <cluster> \
  --cluster-type connectedClusters --name logicapps-aca-extension \
  --query provisioningState -o tsv          # -> Succeeded
kubectl get svc microsoft-app-environment-k8se-envoy -n logicapps-aca-ns   # EXTERNAL-IP from your pool

Step 5: Create a custom location

Turn on the custom-locations feature, then create the location that ties the cluster, extension, and namespace together:

az connectedk8s enable-features -n <cluster> -g <rg> \
  --features cluster-connect custom-locations \
  --custom-locations-oid $(az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv)

EXT_ID=$(az k8s-extension show -g <rg> --cluster-name <cluster> \
  --cluster-type connectedClusters --name logicapps-aca-extension --query id -o tsv)
CC_ID=$(az connectedk8s show -g <rg> -n <cluster> --query id -o tsv)

az customlocation create \
  --resource-group <rg> --name <custom-location> \
  --location <region> --host-resource-id $CC_ID \
  --namespace logicapps-aca-ns --cluster-extension-ids $EXT_ID

One thing we tripped on: the extension type isn't offered in every Azure region. It's registered in eastus, westus, westeurope, and a handful of others, but not eastus2 at the time of writing. The connectedCluster resource's region is independent of where the node actually runs, so pick a supported one here.

Step 6: Create the connected environment

CL_ID=$(az customlocation show -g <rg> -n <custom-location> --query id -o tsv)

az containerapp connected-env create \
  --resource-group <rg> --name <env-name> \
  --location <region> --custom-location $CL_ID

Because MetalLB already put an EXTERNAL-IP on the envoy LoadBalancer service, the platform picks it up automatically. --static-ip is only needed if you went the NodePort + external LB route in Step 2, in which case you pass your LB's VIP here.

Step 7: Configure cluster DNS

App hostnames like *.<env>.<region>.k4apps.io need to resolve to the Envoy ingress from inside the cluster. On AKS or OpenShift, az containerapp arc setup-core-dns handles this. RKE2 isn't a supported distro on that command yet, so it's manual, but it's a small manual.

The extension already writes the correct rewrite and forward rules into a coredns-custom ConfigMap. What's missing is CoreDNS mounting that ConfigMap and importing it from the Corefile.

We tried the direct route first: patch the Corefile ConfigMap, edit the Deployment to add the volume, restart. It works, right up until the next rke2-server restart. RKE2's helm controller re-renders both objects from the chart and wipes your changes. The right way is a HelmChartConfig. The rke2-coredns chart exposes extraConfig (config outside the default zone block) and extraVolumes/extraVolumeMounts, which is exactly what we need:

# /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-coredns
  namespace: kube-system
spec:
  valuesContent: |-
    extraConfig:
      import:
        parameters: /etc/coredns/custom/*.server
    extraVolumes:
      - name: custom-config-volume
        configMap:
          name: coredns-custom
          optional: true
    extraVolumeMounts:
      - name: custom-config-volume
        mountPath: /etc/coredns/custom

Drop the file in /var/lib/rancher/rke2/server/manifests/, or kubectl apply -f it (the helm controller watches both). Within a minute CoreDNS redeploys with the mount and the top-level import. This time it survives restarts and RKE2 upgrades because the chart is now the source of truth.

To verify, run nslookup test.<env-domain> from a throwaway pod. You should get back the microsoft-app-environment-k8se-envoy-internal ClusterIP.

One last DNS thing: a kube-dns alias. The Logic Apps platform locates cluster DNS by looking for a Service named kube-dns in kube-system. That's the convention on AKS, K3s, kubeadm, and most other distros. RKE2 uses rke2-coredns-rke2-coredns and doesn't ship the alias, so the platform can't find DNS. Symptom: revision calls come back as 502s. Fix: create the alias.
apiVersion: v1
kind: Service
metadata: { name: kube-dns, namespace: kube-system, labels: { k8s-app: kube-dns } }
spec:
  selector: { k8s-app: kube-dns }
  ports:
    - { name: dns, port: 53, protocol: UDP, targetPort: 53 }
    - { name: dns-tcp, port: 53, protocol: TCP, targetPort: 53 }
It's a plain Service. Nothing about it gets templated or overwritten, so it just stays put across reconciles and upgrades.

Step 8: Create and deploy a Logic App

Plumbing's out of the way. In the portal, create a new Logic App (Standard) with the Hybrid hosting option, point it at your connected environment, wire storage up to your SMB share, and create. Author the workflow the way you always would. The runs will execute on your RKE2 cluster instead of in Azure.

Troubleshooting: the RKE2 things we hit

Symptom	Cause & fix
Test `LoadBalancer` / envoy stays `<pending>`	No LB provider on the cluster. Install MetalLB (Step 2). RKE2 ships no ServiceLB.
Runtime pods `CrashLoopBackOff` with `inotify instances ... reached`	Node `fs.inotify.max_user_instances` too low. Raise it to 8192 and restart the pods (Step 4).
Revision invoke returns 502	Platform can't find a `kube-dns` Service; RKE2's CoreDNS is under a different name. Add the alias (Step 7).
App hostnames don't resolve inside the cluster	CoreDNS isn't loading `coredns-custom`. Apply the `HelmChartConfig` (Step 7).
Extension type "not registered in region"	The Arc cluster is in an unsupported region. Reconnect it in a supported one; it's independent of where the node runs (Step 5).
Cluster shows Arc Offline after a reboot; `azure-arc` pods `Unknown`	Stale pods from an ungraceful stop. `kubectl delete pods --all -n azure-arc --force` and they'll recreate and reconnect.

References

Announcing Flat File Schema Generation support in Azure Logic Apps Standard

Shree_Divya_M_V — Thu, 09 Jul 2026 07:02:22 GMT

We’re excited to announce the preview of Flat File Schema Generation for Azure Logic Apps Standard. This new built-in action helps integration teams move faster by generating BizTalk compatible flat-file XSD schemas directly from sample flat-file payloads, reducing the manual effort required to model CSV, delimited, and positional files before encoding or decoding them in workflows.

Why this matters

Flat files continue to power enterprise mission critical integrations, from partner feeds and batch exports to finance ledgers, operational reports, and legacy system exchanges. While Azure Logic Apps already helps teams encode and decode flat files, creating the required flat-file schema has often been a separate design-time step. With Flat File Schema Generation, you can now accelerate that onboarding experience by generating a starter schema from real sample data within the workflow itself.

What’s new

The new Flat File Schema Generation action generates a flat-file XSD schema from sample content that you pass into the action. The generated schema includes BizTalk-compatible flat-file annotations, making it suitable for downstream Flat File Encoding and Flat File Decoding actions in Azure Logic Apps Standard workflows.

Runtime schema generation: Generate schemas directly from sample flat-file payloads in the workflow.
Delimited and positional support: Create schemas for common CSV, semicolon-delimited, tab-delimited, and fixed-width files.
BizTalk-compatible annotations: Use generated schemas with the existing flat-file processing model familiar to BizTalk and enterprise integration teams.
Flexible naming: Configure root element names, namespaces, record names, delimiters, and field positions to match your integration needs.

How it works

You provide a representative sample payload, specify whether the file structure is delimited or positional, and configure the relevant parsing details such as field delimiters, record delimiters, header handling, or fixed-width field positions. Once you run the workflow, the action returns the generated XSD schema as XML output, which can then be passed into subsequent flat-file operations or stored as part of your onboarding flow.

Get started

To try the preview, add the Flat File Schema Generation action to a Logic Apps Standard workflow, provide a sample flat-file payload, choose the record structure, and configure the field or record settings that match your format. Use the generated schema output with Flat File Decoding or Encoding in the same workflow or incorporate it into your broader onboarding process for flat-file integrations.

Reference document: Encode, Decode, or Generate Schemas for Flat Files - Azure Logic Apps | Microsoft Learn.

A walkthrough of generating a flat-file schema from sample data

Use the following walkthrough to try the preview end to end with a simple customer order file. The same pattern can be adapted for semicolon-delimited, tab-delimited, or fixed-width positional files.

Delimited sample:

For this example, assume a trading partner sends a comma-separated order file with a header row and repeating order records.

Sample file:
OrderId,CustomerName,OrderDate,Amount,Region
10001,Contoso Retail,2026-07-01,1250.75,North
10002,Fabrikam Foods,2026-07-02,890.00,West
10003,Northwind Traders,2026-07-03,2400.50,South

Configuration values

Parameter	Example value
Record Structure	Delimited
Has header	Yes
Record delimiter	newline
Field delimiter	,
Field delimiter order	Infix
Escape character	Double quote, if the source file uses quoted values
Root element name (Advanced Parameters)	Orders
Record name (Advanced Parameters)	Order
Target namespace (Advanced Parameters)	http://schemas.contoso.com/orders

In the Azure portal, open your Logic Apps Standard resource and select the workflow where you want to generate the schema.
Add a trigger, such as When an HTTP request is received, or use any trigger/action that provides the sample flat-file content.
Add a new action and search for Flat File.
Select the Flat File Schema Generation action.
In the action, provide the sample flat-file content.
Select the file structure type. For this example, choose Delimited.
Enter the schema metadata under advanced parameters, such as the root element name, record name, and target namespace.
Configure the delimiter settings, including the field delimiter and record delimiter.
If the first row contains column names, enable the option to use the first row as headers.
Save and run the workflow.
Open the workflow run history and review the action output. The action returns a generated XSD schema with flat-file annotations.
Review the generated schema, validate field names and inferred data types, and use the schema with Flat File Decoding or Flat File Encoding in your workflow.

Positional sample: Fixed-width customer order file

Use this example when the source flat file doesn’t use delimiters. In a positional, or fixed-width, file each field starts and ends at a known character position. The schema generation action needs those field positions so it can split each record correctly.

Sample positional file:
10001CONTOSO00120260701000125075NORTH
10002FABRIKAM0120260702000089000WEST·
10003NORTHWIND120260703000240050SOUTH

Note: The dot symbol in the second record represents a trailing space used for fixed-width padding. Replace it with an actual space in your real sample payload.

Field position map

Field	Start position	Length	Justification	Example value
OrderId	1	5	Right	10001
CustomerCode	6	10	Left	CONTOSO001
OrderDate	16	8	Right	20260701
Amount	24	9	Right	000125075
Region	33	5	Left	NORTH

Configuration values for the positional sample

Parameter	Example value
Record Structure	Positional
Has Header	No
Record delimiter	newline
Field positions	Use the field names, lengths, and justification values from the field position map.
Root element name (Advanced Parameters)	Orders
Record name (Advanced Parameters)	Order
Target namespace (Advanced Parameters)	http://schemas.contoso.com/orders/positional

Step-by-step walkthrough for positional files

In the Azure portal, open your Logic Apps Standard resource and select the workflow where you want to generate the schema.
Add a trigger, such as When an HTTP request is received, or use an existing action that provides the fixed-width file content.
Add a new action and search for Flat File.
Select the Flat File Schema Generation action.
Paste the positional sample payload into the sample content input. Make sure every record has the same total length.
For the structure type, choose Positional.
Enter the schema metadata, including root element name, record name, and target namespace.
Configure the record delimiter. For this example, use newline.
Add the field positions in order: OrderId length 5, CustomerCode length 10, OrderDate length 8, Amount length 9, and Region length 5.
Set justification for each field. Use Right for numeric or date-like fields and Left for text fields that may contain trailing space padding.
Save and run the workflow.
Open the workflow run history and review the generated XSD schema output. Confirm that the field names, order, lengths, and positional annotations match the source record layout.
Use the generated schema with Flat File Decoding to parse incoming fixed-width files into XML, or with Flat File Encoding to generate outbound fixed-width files.

Limitations and known issues

Limitation	Description
Type inference uses a single record.	The first non-empty data record determines column types.
Single record type only	The action generates one repeating record structure and doesn't support heterogeneous record layouts.
No nested or hierarchical records	The generated schema is flat, meaning you have a root element with one repeating child record and fields.
Positional boundaries aren't automatically detected.	You must provide exact field lengths in field Positions.
UTF-8 code page only	Generated schema sets codepage="65001" and doesn't expose encoding selection.
Escape-character behavior is literal.	Escape handling matches literal value and skips only the next single character.
recordName default	If unspecified, defaults to {RootElementName}_Record.
Designer justification input	fieldPositions[].justification supports only Left and Right.

Looking ahead

This preview is another step toward making Azure Logic Apps Standard, a more complete and productive platform for enterprise integration modernization. Whether you are onboarding new partner feeds, modernizing BizTalk-style flat-file processing, or automating recurring operational files, Flat File Schema Generation helps reduce setup friction and get integration workflows moving faster.

Hybrid Logic Apps Deployment on Red Hat OpenShift

anandgmenon — Tue, 21 Jul 2026 05:13:20 GMT

What makes OpenShift different?

If you've done this on K3s or AKS, most of the flow is identical as mentioned in Set up your own infrastructure for Standard logic app workflows - Azure Logic Apps | Microsoft Learn. Two OpenShift specifics are worth flagging up front. First, SCCs: the default restricted-v2 policy blocks the elevated permissions the runtime and CSI driver need, so you grant the right SCCs before installing (Step 2). Second, DNS: OpenShift runs DNS through the openshift-dns operator rather than the kube-system/coredns you'd find on AKS, so the DNS setup targets that instead (Step 7).

Prerequisites

Requirement	Notes
Azure subscription	With rights to create Arc resources, custom locations, and connected environments.
Azure CLI	Latest, with the connectedk8s, k8s-extension, customlocation, and containerapp extensions.
OpenShift cluster	Self-managed OpenShift (bare metal, datacenter, or Single-Node OpenShift), or ARO. oc logged in as a cluster-admin. Newer OCP is better (some storage options are GA only on 4.18+). Don't have one yet? See the install links under References section below
A SMB file share	a SMB file share discoverable from the cluster to store workflow artifacts
Ingress / load balancer	On self-managed OpenShift you provide the ingress IP yourself: an in-cluster LB (MetalLB or similar) or an external L4 LB in front of a NodePort. See Choose your ingress path below. (ARO provides it automatically.)

Install/confirm the CLI extensions:

az extension add --name connectedk8s az extension add --name k8s-extension az extension add --name customlocation az extension add --name containerapp

Choose your ingress path (self-managed)

Every app is reached through one shared Envoy ingress, and that ingress needs an IP clients can hit. A self-managed cluster has no cloud load balancer to hand one out, so this is the piece you provide. Two options work well; pick whichever fits your environment:

Option	How it works	You set up	Best when
In-cluster load balancer	A bare-metal LoadBalancer controller gives the envoy LoadBalancer service an IP from a pool on your node subnet. MetalLB is the common pick; kube-vip, Cilium, and OpenELB work the same way	Install the controller + an address pool; envoy.serviceType=LoadBalancer	You have a spare IP range on the node network and want a self-contained cluster
External LB + NodePort	Any external L4 load balancer forwards to a NodePort on every node. That can be an appliance (F5, NetScaler, HAProxy, a hardware VIP…) or an Azure Standard Load Balancer when your nodes are Azure VMs in the same region	envoy.serviceType=NodePort; wire your LB → NodePort	You already run a datacenter load balancer, or your cluster runs on Azure VMs

Your choice affects exactly two later steps: the envoy.serviceType value in Step 4, and which IP you pass to --static-ip in Step 6. Nothing else changes.

On ARO you can skip this section. Leave envoy.serviceType=LoadBalancer and the cloud controller assigns the EXTERNAL-IP for you; the rest of the guide is unchanged.

Step 1: Connect your OpenShift cluster to Azure Arc

oc login <api-url> -u kubeadmin oc whoami # should be able to run cluster-admin actions

Connect the cluster to Arc:

az connectedk8s connect --name <cluster> --resource-group <rg>

Step 2: Install the SMB CSI driver

helm repo add csi-driver-smb https://raw.githubusercontent.com/kubernetes-csi/csi-driver-smb/master/charts helm repo update helm install csi-driver-smb csi-driver-smb/csi-driver-smb \ --namespace kube-system --version v1.16.0 \ --set image.smb.repository=mcr.microsoft.com/oss/kubernetes-csi/csi-driver-smb

Step 3: Grant the required SCCs (OpenShift-specific)

The extension installs with Helm --atomic, so if any pod is denied byrestricted-v2 the entire install rolls back. Grant the SCCs to the install
namespace's service accounts before installing:

oc create namespace logicapps-aca-ns oc adm policy add-scc-to-group anyuid system:serviceaccounts:logicapps-aca-ns oc adm policy add-scc-to-group privileged system:serviceaccounts:logicapps-aca-ns oc adm policy add-scc-to-group hostnetwork system:serviceaccounts:logicapps-aca-ns

Step 4: Install the Container Apps extension

Now install the extension that turns the cluster into a Logic Apps host. The command is the same for every cluster; the only line that depends on your ingress choice is the last one, envoy.serviceType:

az k8s-extension create \ --resource-group <rg> --cluster-name <cluster> \ --cluster-type connectedClusters --name logicapps-aca-extension \ --extension-type Microsoft.App.Environment \ --release-train stable --auto-upgrade-minor-version true --scope cluster \ --release-namespace logicapps-aca-ns \ --configuration-settings "Microsoft.CustomLocation.ServiceAccount=default" \ --configuration-settings "appsNamespace=logicapps-aca-ns" \ --configuration-settings "clusterName=<env-name>" \ --configuration-settings "keda.enabled=true" \ --configuration-settings "keda.logicAppsScaler.enabled=true" \ --configuration-settings "keda.logicAppsScaler.replicaCount=1" \ --configuration-settings "containerAppController.api.functionsServerEnabled=true" \ --configuration-settings "functionsProxyApiConfig.enabled=true" \ --configuration-settings "Azure.Cluster.Distribution=openshift" \ --configuration-settings "coreDNSVersion=1.8.6" \ --configuration-settings "envoy.serviceType=LoadBalancer"

The two OpenShift-specific settings:

Setting	Why
Azure.Cluster.Distribution=openshift	Renders the chart's OpenShift branch with the privileged security contexts OpenShift requires.
coreDNSVersion=1.8.6	Makes the DNS config the setup generates compatible with OpenShift's resolver so app hostnames resolve. Keep this value.

Ingress setting, per your path:

In-cluster LB (e.g. MetalLB) → envoy.serviceType=LoadBalancer (as above); the LB controller assigns the EXTERNAL-IP from your pool.
External LB (on-prem) → envoy.serviceType=NodePort plus envoy.nodeHttpsPort=30443 and envoy.nodeHttpPort=30080, then point your
external L4 LB at those NodePorts.
ARO → leave envoy.serviceType=LoadBalancer; Azure assigns the EXTERNAL-IP automatically.

Wait for the extension and read the ingress IP:

az k8s-extension show -g <rg> --cluster-name <cluster> \ --cluster-type connectedClusters --name logicapps-aca-extension \ --query provisioningState -o tsv # -> Succeeded oc get svc microsoft-app-environment-k8se-envoy -n logicapps-aca-ns # LoadBalancer: EXTERNAL-IP | NodePort: 80:30080, 443:30443 (EXTERNAL-IP stays <none>)sample of envoy service using external LB

Step 5: Create a custom location

EXT_ID=$(az k8s-extension show -g <rg> --cluster-name <cluster> \ --cluster-type connectedClusters --name logicapps-aca-extension --query id -o tsv) CC_ID=$(az connectedk8s show -g <rg> -n <cluster> --query id -o tsv) az customlocation create \ --resource-group <rg> --name <custom-location> \ --location <arc-region> --host-resource-id $CC_ID \ --namespace logicapps-aca-ns --cluster-extension-ids $EXT_ID

Step 6: Create the connected environment

The connected environment is the Logic Apps environment your apps live in. Whether you set --static-ip depends on your ingress:

External LB + NodePort: pass --static-ip <your LB VIP>. The envoy service is a NodePort with no EXTERNAL-IP, so the platform can't discover the ingress IP on its own; you give it the LB VIP explicitly.
In-cluster LB (MetalLB) or ARO: you can omit --static-ip. The platform uses the EXTERNAL-IP already assigned to the envoy LoadBalancer service.

CL_ID=$(az customlocation show -g <rg> -n <custom-location> --query id -o tsv) az containerapp connected-env create \ --resource-group <rg> --name <env-name> \ --location <arc-region> --custom-location $CL_ID \ --static-ip <your-lb-vip> # external LB + NodePort; omit for in-cluster LB / ARO

When you do set --static-ip, it's create-only. You can't patch it later; to change it you delete and recreate the environment.

Step 7: Configure cluster DNS

So that app hostnames resolve to the Envoy ingress inside the cluster, run the DNS setup with the OpenShift flag:

az containerapp arc setup-core-dns --distro=openshift --verbose

This creates a small coredns-custom service and adds a zone-scoped forward in OpenShift's DNS Operator that covers only the environment's domain. Every other name (internet, *.svc.cluster.local, your own domains) is left alone.

Step 8: Create and deploy a Logic App

You can now target the connected environment from the portal or CLI, exactly like any Logic App Standard. In the portal, choose Logic App (Standard) → Hybrid, pick your connected environment, point storage at your SMB share, and create.

Once the logic app is ready, you are now ready to author and test workflows hosted in your openshift cluster.

Troubleshooting common issues

Symptom	Cause & fix
Extension install fails and rolls back with SCC/PodSecurity denials	SCCs not granted before install. Grant anyuid + privileged + hostnetwork to the install namespace (Step 2), then retry.
UnauthorizedNamespaceError / 401 during onboarding	Custom-locations RBAC incomplete. Re-run enable-features … --custom-locations-oid <oid>; ensure the caller has Contributor/Azure Arc Kubernetes Cluster Admin.
App pods stuck ContainerCreating, PVC Pending	SMB driver missing/misregistered. Confirm a smb.csi.k8s.io CSIDriver exists and its pods are Running. Install one driver only.
Envoy has no EXTERNAL-IP on bare metal	No LoadBalancer provider. Install an in-cluster LB (MetalLB or similar) or front NodePort with an external LB (ARO does this automatically).

References

Setting up an OpenShift cluster

Logic Apps Hybrid

Set up Logic Apps Hybrid deployment

Coding with Logic Apps Standard: Local Functions

hcamposu — Tue, 07 Jul 2026 05:38:35 GMT

Welcome to the Series

Welcome to the first article in the Coding with Logic Apps Standard series. This series is for integration developers, architects, and modernization teams who want to go beyond visual workflow design and use Azure Logic Apps Standard as a complete development platform for enterprise integration. In this post, we focus on Local Functions: the ability to write, debug, and deploy custom .NET code together with your workflows, inside the same Logic Apps Standard project.

Customers often assume that meaningful custom code in an integration solution must be implemented as a separate Azure Function. Azure Functions are a powerful option for reusable APIs, independent compute workloads, and enterprise-wide services. But when custom code exists to support an integration workflow—validating a message, enriching a payload, shaping data for a connector, or applying business-specific logic—Local Functions provide a simpler, more cohesive, and more integration-native option inside Logic Apps Standard.

Does Logic Apps Standard run on top of Azure Functions?

Before we go deeper, it is important to clarify the relationship between Logic Apps Standard and Azure Functions. Logic Apps Standard is not a workflow layer that simply runs on top of Azure Functions. Instead, Logic Apps Standard uses a Functions host that is specialized for integration workloads. That distinction matters because an integration platform has different requirements than a code-only compute service.

A typical Azure Functions app is created around a specific language stack, such as .NET, Java, Node.js, Python, or PowerShell. That model works well when the application is primarily a code-first service. Logic Apps Standard has a different goal. A single integration application might orchestrate workflows, use built-in connectors, run JavaScript for workflow logic, call local .NET code through Local Functions, use JDBC-based connectivity, and execute scripts as part of the same integration solution.

Logic Apps Standard supports this model through dynamically isolated language workers. The runtime can inspect the workflow and start the worker that is needed for that integration scenario. For example, a workflow that uses JDBC can start the Java worker, while a workflow that uses custom C# code can start the isolated .NET worker. The goal is not to make customers think about processes. The goal is to let the integration application use the right technology for each part of the flow, with little latency difference for typical workflow use.

For iPaaS scenarios, this is important. To achieve the same multi-language result with standalone Azure Functions, customers may need multiple Function Apps, each aligned to a different language stack. That adds more resources, deployment units, configuration surfaces, and operational overhead. In Logic Apps Standard, the same integration scenario can often run inside a single Logic App application: built-in connectors plus the isolated language worker needed for the workflow, rather than several separate Function Apps. Azure Functions remains a strong option for independent compute services, while Logic Apps Standard provides the integration application model for workflows, connectors, and workflow-scoped code.

Why Local Functions?

Logic Apps Standard goes beyond being a workflow engine. It is also a runtime where built-in connectors, workflow orchestration, and custom code can work together as one solution. Local Functions make this especially valuable because they let you place custom .NET logic directly beside the workflow that needs it. The Logic Apps runtime and function execution run alongside each other in the same application process model, so when the code is part of the workflow, it can scale with the Logic App, deploy with the Logic App, and be operated as part of the same application boundary—without requiring a separate endpoint, separate authentication model, or separate runtime resource to manage.

This matters because the strongest integration solutions are not built from code alone. They combine the reach of connectors with the precision of custom logic. A workflow might receive a message from IBM MQ, read reference data from SQL, decode EDIFACT messages, call SAP, or an API, transform a payload, and then invoke local custom code to apply partner-specific validation or business rules before sending the result to the next system. The outcome is unique: built-in connectors handle the connectivity and integration plumbing, while Local Functions handle the specialized code that makes the solution fit the business. With Local Functions you:

Keep workflow and code together when the code is part of the integration process.
Debug locally in one experience across workflow steps and custom .NET logic.
Deploy as one solution without introducing a separate Function App for workflow-scoped code.
Operate as one application with code that scales, deploys, and is managed together with the Logic App.
Avoid unnecessary integration boundaries when there is no need to manage a separate endpoint, authentication flow, or runtime resource for workflow-specific code.
Improve simplicity and security by avoiding the need to onboard and harden multiple application resources in the network, reducing the exposed surface area for workflow-scoped code.
Simplify cost management for workflow-scoped code because Local Functions run within the Logic Apps Standard application boundary and do not require a separate Azure Functions resource when the code belongs to the workflow.
Modernize BizTalk-style custom logic into a cloud-native workflow model while preserving valuable .NET investments.

However, this is not about choosing Local Functions instead of Azure Functions in every scenario. Azure Functions are excellent when you need an independently hosted, reusable, code-first service. The opportunity is to use Local Functions first when the code naturally belongs with a Logic Apps integration solution. In those cases, the workflow, connectors, and custom code run side by side in the same application boundary, scaling together, deploying together, being managed together, and avoiding the need to introduce a separate Azure Functions resource for code that is only used by that workflow.

What are common scenarios for Local Functions?

Local Functions are best for workflow-scoped code: logic that is meaningful only in the context of a Logic Apps Standard workflow and benefits from being deployed, scaled, secured, and operated with that workflow. Common scenarios include:

Message validation and enrichment before or after connector calls to systems such as SQL, Service Bus, SAP, IBM MQ, DB2, HTTP APIs, or partner endpoints.
Custom parsing or formatting for proprietary, irregular, or partner-specific payloads that do not fit simple workflow expressions or mappings.
Business rules and calculations that are too specific for generic workflow expressions but do not need to become independent services.
BizTalk modernization where existing .NET helper assemblies, orchestration utilities, pipeline-adjacent logic, enrichment routines, or host-specific formatting can move closer to Logic Apps workflows.
Modernization from Java-oriented integration platforms such as MuleSoft, Boomi, or TIBCO BusinessWorks when customers decide to refactor workflow-scoped Java, Groovy, JavaScript, or XPath helper logic into .NET as part of their move to Logic Apps Standard.

When to use Local Functions versus Azure Functions

Azure Functions and Local Functions are complementary. Azure Functions are a great fit for independent services, shared APIs, and event-driven compute that should live outside a single workflow application. Local Functions are a great fit when the code is part of the integration workflow itself and benefits from running alongside the Logic Apps runtime in the same application process model, sharing the same lifecycle, scale, deployment, and operational boundary as the Logic App. You can use the following guidance:

Local Functions are the better fit when...	Azure Functions are the better fit when...
The code is workflow-specific and should live with the Logic Apps Standard project.	The code is a reusable service consumed by multiple applications, workflows, or teams.
You want the workflow and code to scale together as part of the same Logic App.	You need an independent scaling boundary for the code.
You want to deploy workflow definitions, connectors, configuration, and custom code together.	You need a separately deployed API, microservice, or event-driven compute component.
You want to avoid managing a separate endpoint, authentication flow, runtime resource, and Azure Functions-specific cost model for workflow-scoped logic.	You need the code to be exposed, secured, versioned, or operated as an independent service.
The code complements built-in connectors by validating, enriching, calculating, or shaping integration data inside the workflow.	The code is the primary compute workload and the workflow is only one possible caller.
You are modernizing BizTalk-style helper assemblies, orchestration helpers, or pipeline-adjacent logic that belongs with the integration flow.	You are building a broader platform capability that should live outside a single workflow application.

While cost can also be part of this decision, it should be framed in architectural terms. When custom code is implemented as a separate Azure Function, the solution introduces another Azure resource with its own hosting, billing, deployment, monitoring, and security considerations. When the code is workflow-scoped, Local Functions let that code run within the Logic Apps Standard application boundary, alongside the workflows and connectors that use it. This can simplify the overall cost model because the team does not need to add a separate Azure Functions resource just to host code that belongs to the integration workflow.

The Bigger Opportunity: In-App Connectors Plus Code

The most important reason to consider Local Functions is not just convenience. It is the integration outcome. Logic Apps Standard gives you native workflow orchestration and a broad In-app connector ecosystem. Local Functions add the ability to bring custom code of all kinds into that same solution boundary. Together, they let you build integrations where the platform handles connectivity, reliability, retries, monitoring, orchestration, and iPaaS semantics, while your code handles the business-specific decisions that make the workflow unique.

For customers who are defaulting to Azure Functions because they believe Logic Apps cannot host meaningful code, Local Functions change the conversation. Azure Functions remain a strong option for independent compute and reusable services. But when the code belongs to the integration flow, Logic Apps Standard can be the place where connectors, workflow logic, and local code meet: connectors to reach systems, workflow logic to coordinate the process, and local code to implement the specialized behavior that customers need. The value is not that one runtime replaces the other; it is that Logic Apps and function execution can run alongside each other, each providing unique value inside the same integration application boundary. For workflow-scoped code, that same boundary also helps avoid adding a separate Azure Functions resource, with its own deployment, authentication, monitoring, scaling, and cost model, when the code is only needed by the Logic App.

CI/CD

Local Functions fit naturally into the same CI/CD model as Logic Apps Standard workflows. The workflow definitions, connections, configuration, and workflow-scoped .NET code can live in the same project. They can also move through the same build, test, and deployment process. This means teams can package the Logic Apps Standard application once and promote it across development, test, staging, and production environments. When the code belongs to the workflow, Local Functions help avoid a separate deployment pipeline, release process, and operational boundary for a standalone Azure Functions resource.

Looking Ahead

In the next articles in the Coding with Logic Apps Standard series, we will continue exploring the developer side of Logic Apps Standard. The goal is to help customers see Logic Apps Standard not only as a low-code workflow designer, but as a mission-critical integration development platform where connectors and code work together, and where workflows can be created, managed, and deployed as code.

Logic Apps Aviators Newsletter - July 2026

WSilveira — Mon, 06 Jul 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

July 2026's Ace Aviator: Bill Chesnut

Bill Chesnut - Cloud Platform and API Evangelist @ SixPivot

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

Cloud Platform and API Evangelist for SixPivot based in Melbourne, Australia - Everything Integration.

Can you give us some insights into your day-to-day activities?

My day-to-day activities are very much the same every day: some days working on Azure Landing Zones for Integration, developing Logic Apps and Function Apps, and supporting existing Azure Integration and BizTalk.

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

I really enjoy helping others learn about technology and solve their business problems. At the start of my BizTalk journey in the early 2000s, I also did a lot of BizTalk training across Australia and NZ for Microsoft. When Azure Integration came around, I also created a Cloud Integration Training course that I delivered for SixPivot.

Looking back, what advice do you wish you had been given earlier?

Always keep your mind open to new things, and never stop learning.

What has helped you grow professionally?

Staying involved in the community has really helped me grow professionally. You are always encountering new things and meeting interesting people.

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

The one thing I use a lot in my development is Azure App Configuration. It would be nice to be able to create parameters and link them inside the logic app to Azure App Configuration, instead of in the environment variables.

News from our product group

On the road to .NET 10 Support: Logic Apps Migration from In-Proc to Out-of-Proc hosting model

Microsoft is migrating Logic Apps Standard from the in-proc to the Azure Functions out-of-proc hosting model as a step toward .NET 10 support. For most customers the change is automatic with no action required, but apps using the NuGet-based deployment model need manual preparation. Teams must preserve the LOGICAPP_INPROC_REDIRECT=1 app setting in their deployment pipelines to prevent premature auto-migration until the app is ready. Key points: the rollout begins around July 30, 2026; automatic migration happens on app restart for apps without the redirect flag; NuGet-based apps must download the latest Functions Core Tools, update project configuration to out-of-proc, and validate locally before removing the redirect setting.

Dynamic Connection Properties in Azure Logic Apps Standard

Logic Apps Standard now supports dynamic connection names for built-in (service provider) connectors, solving the problem where a single workflow shared by multiple teams previously required duplicated workflows or hardcoded connections. Instead of hardcoding a connection name, you supply any workflow expression—trigger inputs, action outputs, parameters, or conditional logic—in the connectionName field, and the runtime resolves it against connections.json at execution time. Key points: define multiple connections (one per team/environment/tenant) in connections.json; resolve names via expressions like @triggerBody(), headers, or if() conditionals; works today only via Code View with no designer support; illustrated with a step-by-step dynamic SFTP connection example using app settings for credentials.

Productize, observe, version, and automate MCP servers in Azure API Management

As organizations move from AI-assisted apps to agentic workflows, MCP servers become a critical integration layer between agents, tools, APIs, and enterprise systems. Azure API Management already brings MCP servers under governance, but scaling adoption demands deeper management. This post announces new generally available capabilities that make MCP servers first-class managed resources. Key points: add MCP servers to Products to package and govern capabilities for specific consumers; MCP tool observability to trace tool usage, logs, errors, and payload context; MCP server versioning to run multiple versions side by side and manage change safely; and Management API plus Bicep support to automate MCP configuration in CI/CD—applying familiar API governance patterns (products, subscriptions) to MCP.

Automatically Route Azure Service Health Alerts to the Right Service Owners Using Agentic Logic Apps

Azure Service Health alerts often land in a shared mailbox, requiring manual triage across platform, database, application, security, and AI teams. This post shows how to automate routing by combining Service Health, Azure Monitor Action Groups, and an Autonomous Agent Logic App. The agent matches impacted services to an ownership map and notifies the correct stakeholders, with a fallback for unmapped services. It covers configuring Service Health alerts, triggering Logic Apps from Action Groups, maintaining the service-to-owner repository, and designing agentic routing to reduce operational overhead and response delays.

News from our community

DLQ Replay Is Not a Recovery Strategy

Post by Al Ghoniem, MBA

This article explains why dead-letter queue (DLQ) replay is not a true recovery strategy in distributed systems. A DLQ contains failed messages but cannot decide if replay is business-safe, especially when downstream operations may have already committed. The author outlines risks like duplicate postings and incorrect outcomes, and proposes a controlled replay workflow with idempotency keys, reconciliation steps, failure classification, RBAC, and detailed observability. Practical guidance includes preserving original command context, checking an idempotency store before action, and exposing replay through API Management for governance. A simple decision tree and logging model support auditability and operational safety.

Naming conventions for Azure Integration Services: How I structure a Hybrid Integration Platform in Microsoft Azure

Post by Şahin Özdemir

This practical guide sets out a consistent naming convention for Azure Integration Services within a hybrid integration platform. It explains why disciplined naming improves readability, maintainability, RBAC clarity, and automation for IaC and DevOps. The core formula—resource-org-workload-integration-context-environment—is applied across three architectural tiers (core, shared, integration), with detailed examples for resource groups, virtual networks, subnets, NSGs, Function Apps, Logic Apps Standard, and API connections. The article covers lowercase and hyphen rules, storage account exceptions, and workflow naming (receiver, processor, sender, helper, agent loops). It also touches on claim-check patterns, observability artifacts, and practical constraints like Key Vault name limits.

Building Azure Logic Apps Agent Tools: Connectors and MCP

Post by Steef-Jan Wiggers

Part 4 of the Logic Apps Agent Loop series dives into tools—the mechanisms that let an agent interact with the world. It describes three layers: built-in and managed connectors for common integrations, custom connectors wrapping internal REST APIs for reuse across a tenant, and MCP servers that invert the model by exposing a Logic Apps workflow as a tool provider callable by external agents. The post explains agent parameters, naming and descriptions, and shares preview limitations with API Center’s MCP wizard and Azure AI Foundry’s OpenAPI tool networking. It offers Azure API Management as a practical workaround and guidance on choosing the right layer.

Creating Azure Sandbox Chatbot with Azure Logic Apps

Post by Adam Marczak

This article outlines a practical Teams-based chatbot pattern for creating ephemeral Azure sandboxes using Azure Logic Apps. A Logic Apps workflow acts as the chatbot, granting users Owner permissions to temporary resource groups that auto-delete after 12 hours, with optional quotas and policies to prevent abuse. It explains single-tenant and multi-tenant setups, Entra objects (service principal, service user), the use of adaptive cards, and governance through tags, Azure Policies, and resource providers. Guidance includes enterprise pipelines (ADO/GitHub) for provisioning, sample workflow screenshots, and GitHub-hosted JSON for the Logic App and adaptive card.

Mastering Enterprise Integration Patterns with Logic Apps

Post by Parth T.

This piece introduces how Enterprise Integration Patterns (EIPs) pair with Azure Logic Apps to build scalable, maintainable cloud-native architectures. It explains the role of Logic Apps as an orchestration platform across APIs and events, and highlights benefits such as reusability, observability, and reduced complexity. The article surveys how messaging and workflow patterns map to Logic Apps constructs, when to apply them in distributed systems, and why integration architecture is increasingly strategic. It invites practitioners to consider their most-used EIPs and positions Logic Apps as a pragmatic way to implement patterns without heavy custom code.

Your Retry Policy Is Not an Idempotency Strategy

Post by Al Ghoniem, MBA

Al Ghoniem clarifies why retries are not a safety mechanism and must be paired with idempotency to avoid duplicate business outcomes. The article distinguishes transport messages, business commands, and outcomes, and outlines practical idempotency keys (client-generated, natural, composite). It places responsibilities across Azure services—APIM as gatekeeper, Service Bus for durability, Functions as command handlers—and insists on a durable store with atomic handling and clear conflict behavior. Guidance covers DLQ replay, Logic App resubmission, payload hashing, and observability in Application Insights. The takeaway: design for safe repetition, not just repeated execution.

When Logic Apps Beat Custom Code (And When They Don’t)

Post by Parth T.

Parth Talaviya explains when Azure Logic Apps deliver the most value and when custom code is the better fit. Logic Apps excel in rapid orchestration, reduced operational overhead, cost-effective common workflows, and a rich connector ecosystem. Custom code is preferred for complex domain logic, high-performance processing, advanced security/compliance needs, and reduced platform dependency. The piece frames the decision as trade-offs, not rivalry, and encourages combining both approaches—using Logic Apps for orchestration and SaaS integrations, and code for core business services. Architecture should track complexity, team capabilities, and long-term maintainability.

Boosting Retention: Managing Execution History in Logic Apps Standard

Post by Anitha Eswaran

This guide explains how to extend or adjust the default 90‑day execution history retention in Logic Apps Standard. It details portal-based configuration and project settings, including Workflows.RuntimeConfiguration.RetentionInDays and Runtime.FlowMaintenanceJob.RetentionCooldownInterval. The article clarifies why some historical runs may persist up to 97 days due to the cleanup cadence, and how retention is calculated based on the run’s start time. It shows how to scope retention globally or per workflow (Workflows..RuntimeConfiguration.RetentionInDays), with practical steps, screenshots, and recommended ranges (7–365 days) to balance troubleshooting visibility and storage considerations.

Choosing the Right AI Agent: Logic Apps Agent Loop vs Microsoft Foundry vs Copilot Studio — Real-Life Scenarios for Architects

Post by Kunal Saha

Kunal Saha compares three Azure agent platforms from a Logic Apps practitioner’s viewpoint. Logic Apps Agent Loop suits event-driven, integration-heavy automation that benefits from adaptive reasoning across connectors. Microsoft Foundry is positioned for multi-agent systems, evaluation rigor, and deep model flexibility beyond OpenAI, making it fit when AI reasoning quality becomes the main engineering challenge. Copilot Studio specializes in conversational Teams experiences, with native publishing and Power Platform connectors. The article offers plain decision rules—event- vs conversation-driven, integration vs AI-centric—and maps five enterprise scenarios to the right choice, urging architects to mix platforms based on problem fit.

Azure Integration Roadmap Sessions

Post by Michael Stephenson

Michael Stephenson previews Microsoft’s Azure Integration roadmap sessions at the Integrate 2026 event. He links teaser videos covering BizTalk migration guidance, API Management roadmap, Logic Apps roadmap, Service Bus, Event Grid, and Event Hub. The piece provides the event page, YouTube playlist, and direct video links per topic. It positions these sessions as high‑value for architects and integration teams planning modernization and migration strategies, and suggests the content will outline direction and capabilities across core Azure Integration Services—useful for those moving BizTalk workloads or strengthening governance around APIs and messaging.

Logic Apps Automation release, what is it, and how it works?

Post by Adam Marczak

Adam Marczak explains the Logic Apps Automation preview: a new AI‑first SKU with a redesigned portal (auto.azure.com), updated hierarchy (Projects → Applications → Workflows), sandboxes, and 0‑to‑N scaling. He contrasts Automation with Standard and Consumption across runtime isolation, scale‑to‑zero, networking, and billing. Noted gaps include CICD export, whole‑project code export, and VNET availability in preview. Practical guidance includes portal screenshots, run history differences (real‑time in Automation), and decision tables suggesting when Automation, Standard, or Consumption fits best. Related reading links to Microsoft docs and Logic Apps Labs content.

Logic Apps and Event Grid: Event-Driven Architecture in Azure

Post by Marcel Broschk

This article explains how Azure Event Grid and Azure Logic Apps combine to enable event-driven architecture at scale. Event Grid provides serverless, high-throughput event routing with filtering, retries, and dead-lettering, while Logic Apps orchestrate multi-step workflows using hundreds of connectors. The piece outlines common patterns, such as reacting to blob uploads to trigger AI extraction, storage, and approvals, and discusses key design considerations like idempotency, error handling, and security with managed identities and private endpoints. It also touches on cost and performance trade-offs and highlights practical use cases across operations, business automation, and hybrid integration.

Introduction to Azure Logic Apps Automation | Getting Started with Azure Logic Apps Automation

Video by Srikanth Gunnala

This introductory video walks through Azure Logic Apps Automation and how to get hands-on quickly. It explains the service’s goals, shows how to start building workflows, and demonstrates connecting triggers and actions to automate tasks with minimal setup. Viewers see how to design a simple end-to-end process, integrate with common Microsoft 365 services, and apply AI-assisted authoring to accelerate workflow creation. The session emphasizes practical steps—where to begin, how to wire inputs and outputs, and what to consider for moving from a demo to production-ready automation.

How To: Call an Azure AI Foundry Agent from a Logic App

Post by Craig Chiffers

Craig Chiffers presents a step-by-step guide for wiring Microsoft Teams to an Azure AI Foundry agent using Azure Logic Apps—without custom connectors or Azure Functions. The walkthrough covers creating a Teams channel trigger, composing and cleaning message content, posting an HTTP request to the agent endpoint, parsing the JSON response, and replying in-thread to Teams. It includes tips for authentication (API key versus Managed Identity), error handling, and formatting replies, plus suggestions for enhancements like conversation history, loop prevention, and reusable patterns. It’s a practical blueprint for bringing agents into everyday workflows.

Healthcare Integration Teams Are About to Get a Lot More Interesting

Post by Gautam Gyanendra

Gautam Gyanendra outlines how healthcare integration teams can evolve by layering agentic workflows on top of deterministic systems. He distinguishes predictable, auditable processes handled by tools like Azure Logic Apps, Service Bus, and API Management from AI-driven reasoning that adapts to context. The article proposes a hybrid architecture where agents summarize charts, detect gaps, and escalate uncertainty to humans, while deterministic layers execute reliably with governance and audit trails. It maps Microsoft services to each layer and explains why combining them will shape healthcare operations over the next three to five years.

Automatically Route Azure Service Health Alerts to the Right Service Owners Using Agentic Logic Apps

Arpit_MSFT — Sun, 05 Jul 2026 21:55:20 GMT

As organizations adopt more Azure services, operational ownership naturally becomes distributed across multiple teams. The platform team may own Azure Kubernetes Service (AKS), the database team may manage Azure SQL, while application teams are responsible for App Services and Logic Apps.

Azure Service Health provides an excellent way to stay informed about service issues, planned maintenance, health advisories, and security events. However, in many environments, all notifications are sent to a shared mailbox or central operations team. Someone must then manually determine which team owns the affected service and forward the alert to the appropriate stakeholders.

While manageable for a small environment, this quickly becomes inefficient as the number of Azure services and teams grows.

In this article, we'll build an automated solution using Azure Service Health, Azure Monitor Action Groups, and an Autonomous Agent Logic App that intelligently routes notifications to the teams responsible for the impacted Azure services.

What You'll Learn

Configure Azure Service Health Alerts
Trigger a Logic App using an Azure Monitor Action Group
Maintain a service-to-owner mapping repository
Use an Autonomous Agent workflow for intelligent routing
Automatically notify the appropriate service owners
Implement a fallback mechanism for unmapped services

The Challenge

Azure Service	Service Owner
Azure App Service	Application Team
Azure SQL	Database Team
Azure Kubernetes Service	Platform Team
Azure OpenAI	AI Operations Team
Microsoft Sentinel	Security Team

Now imagine Azure Service Health generates an advisory for Azure OpenAI.

By default, the notification may be sent to a generic mailbox: cloudops@contoso.com

A member of the operations team must then:

Review the notification
Determine who owns the affected service
Forward the email manually
Track who has been notified

This introduces operational overhead and can delay response times during critical events.

Solution Overview

The solution consists of three Azure services:

Azure Service Health Alert
Azure Monitor Action Group
Azure Logic App (Autonomous Agent)

The Logic App acts as the intelligent routing layer that determines who should receive each Service Health notification.

Service Owner Mapping

To determine who should receive an alert, the Logic App uses a service-to-owner mapping.

In this example, the mapping is stored as a CSV file in Azure Blob Storage.

Services,Owners
Azure App Service,ASPOwners@contoso.com
Azure SQL,DBAOwners@contoso.com
Logic Apps,LAOwners@contoso.com
Azure OpenAI,OpenAIOwners@contoso.com
Azure Kubernetes Service,AKSOwners@contoso.com
Microsoft Sentinel,SentinelOwners@contoso.com
Default,CloudAdmins@contoso.com

Important: Always include a Default entry in your mapping file. If an alert is generated for a service that isn't mapped, the notification will still be routed to a fallback operations team.

Flexible Service Owner Data Source

This solution uses Azure Blob Storage because it's simple to implement, easy to maintain, and suitable for most scenarios.

However, the Service Owner Lookup tool (More information in Step-1 Build the logic app) in the Logic App is only responsible for retrieving ownership information. The underlying data source can be replaced with any repository that best fits your organization's architecture.

Alternative Source	Implementation Approach
SharePoint List or File	Replace the Blob Storage action with a SharePoint connector action.
Azure File Share (SMB)	Use a File connector instead of a Blob connector.
Logic App Parameters	Store a small owner mapping directly within the Logic App or ARM template parameters.
HTTP API / Database	Query an internal REST API, CMDB, Azure Storage Tables or SQL database dynamically.

The key point is that the Autonomous Agent doesn't care where the information comes from.

As long as the lookup tool returns a structured list of service-to-owner mappings, the routing logic remains unchanged.

This flexibility allows organizations to integrate with existing governance platforms, CMDB systems, service catalogs, or internal APIs without modifying the overall workflow.

The Autonomous Agent doesn't directly query Blob Storage. It consumes the output returned by the Service Owner Lookup tool and determines the appropriate recipients for the incoming Service Health event.

Why Use an Autonomous Agent?

Traditional Logic App implementations often rely on numerous switch statements and conditions to determine routing logic.

As service inventories grow, maintaining those conditions becomes increasingly difficult.

Using an Autonomous Agent greatly simplifies the design.

Analyzes incoming Service Health events
Identifies the impacted Azure service
Retrieves ownership information
Selects the correct recipients
Formats and delivers notifications

Maintenance typically becomes as simple as updating the service owner mapping rather than modifying workflow logic.

Step 1: Build the Logic App

For this implementation, create a Consumption (Multi-Tenant) Logic App and select an Autonomous Agent workflow. I have added below tools to my autonomous agent. The template for the logic app is provided in the deployment section below.

Trigger Input Reader

Reads and interprets the Service Health payload received through the Action Group.

Service Owner Lookup

Retrieves the service ownership mapping and identifies the correct recipients.

Send Alert Email

Formats and sends notifications to the identified service owners.

Failure Notification

Notifies Cloud Administrators if workflow execution fails.

The logic app workflow should look like below.

Step 2: Configure the Azure Monitor Action Group

The Azure Monitor Action Group is responsible for invoking the Logic App whenever a matching Service Health event occurs.

Navigate to:

Azure Portal → Monitor → Alerts → Action Groups

You can either create a new Action Group or modify an existing one.

Provide the required information in the Basics section and then navigate to the Actions tab.

Configure the Logic App Action

Select Logic App as the Action Type.
Select the subscription where the Logic App is deployed.
Select the resource group that contains the Logic App.
Select the Logic App created in Step 1.
Choose the HTTP trigger:
- When an HTTP request is received
Provide a friendly name for the Action.
Save the Action Group.

Your configuration should look similar to the example below:

Important: Ensure that the Logic App trigger selected in the Action Group is "When an HTTP request is received". Selecting an incorrect trigger can prevent the Service Health payload from reaching the workflow.

Tip: Service Health notifications use the Service Health alert payload format. The Logic App will receive the complete alert context through the HTTP trigger, allowing the Autonomous Agent to identify the affected Azure service and determine the correct recipients.

Once the Action Group is saved, Azure Monitor will automatically invoke the Logic App whenever a Service Health alert matching your configured criteria is generated.

Step 3: Create the Service Health Alert

Navigate to Azure Service Health and create a Service Health Alert.

Subscription
Services
Regions
Event Types
Severity

Select Use an Existing Action Group and choose the Action Group created earlier.

Validation and Testing

Keep the native Azure Service Health email notifications enabled for a week or two after deployment.

Validate Logic App execution
Validate routing accuracy
Verify email delivery
Test fallback scenarios

Deployment Template

A sample deployment template that provisions the required resources is available on GitHub:

Azure-Service-Health-Alert-Automation

Post-Deployment Requirement

Office 365 Authorization Required

After deployment, navigate to the Office 365 connection resource and complete the authorization process. This OAuth step is required before email notifications can be sent and cannot currently be automated through ARM template deployments.

Cost Considerations

This solution is designed using Azure services that generally follow either a consumption-based or pay-as-you-go pricing model. The overall cost of the implementation depends primarily on the number of Service Health notifications received, Logic App executions, connector usage, and any supporting storage resources.

Azure Service Health

Azure Service Health is available to Azure subscribers at no additional cost.

Azure Monitor Action Groups

Action Groups themselves are used to route notifications and automation actions. Certain notification channels and actions may incur charges depending on the notification type and usage volume.

Azure Logic Apps

This article uses a Consumption (Multi-Tenant) Logic App. In the Consumption model, billing is based on workflow executions, trigger executions, connector actions, and related operations. As a result, costs scale with actual usage, making it a cost-effective option for event-driven workloads such as Service Health notifications.

Supporting Services

Depending on your implementation, additional charges may apply for:

- Azure Blob Storage used to store service-owner mappings
- Office 365 or Outlook connectors used for email delivery
- Custom connectors, APIs, or databases used for owner lookups
- Any monitoring or logging resources used for diagnostics

Tip: Since Service Health events are relatively infrequent in most environments, the operational cost of this solution is typically low. However, it's always recommended to review pricing for the services used in your specific Azure subscription and region.

Official Pricing References

Conclusion

Azure Service Health provides valuable visibility into platform events, but the effectiveness of those alerts depends on whether they reach the people who can act on them.

By combining Azure Service Health, Azure Monitor Action Groups, Blob Storage, and Autonomous Agent Logic Apps, you can build a scalable notification-routing solution that automatically delivers alerts to the teams responsible for the affected services.

The result is less manual effort, faster response times, improved accountability, and a more efficient operational model for managing Azure environments at scale.

On the road to .NET 10 Support: Logic Apps Migration from In-Proc to Out-of-Proc hosting model

WSilveira — Fri, 03 Jul 2026 00:25:23 GMT

We will begin this migration in the coming weeks. For most customers, the change will be automatic and require no action. However, some apps will need customer updates before they can move to the new hosting model. This exception is:

Logic Apps that use the current NuGet-based deployment model

If your app does not fall into one of these categories, it will be migrated automatically and no action is required. If it does, review the guidance in this article to prepare your app for migration.

Getting ready for this update

If your application is using NuGet-based deployment, you should update your deployment processes to preserve the following app setting until your app is ready to move to the new hosting model:

LOGICAPP_INPROC_REDIRECT

This app setting is used to prevent an app from being automatically migrated to the Azure Functions out-of-proc-hosting model. We will update this app setting for apps that fall into the exception categories and will notify customers to update their deployment pipelines so this value is not overwritten.

We will start rolling out a change that will automatically move any app that does not have the above app setting to the Azure Functions out-of-proc-hosting model the next time the app restarts.
As part of the rollout process, we will add this flag to any application that fits the exception criteria. This will be done only once, so subsequent configuration changes could override our setting. This is why you need to update your processes to preserve this value until the app is ready to move.
You must make this change before July 30, 2026. This is when we will be rolling out the changes.

Manual steps needed for NuGet-based applications

If your application is using the NuGet-base deployment model, you will need to make the appropriate updates described below before removing the redirect app setting and allowing the app to move to the Azure Functions out-of-proc-hosting model.

Download the latest Azure Functions Core Tools.
Update your project configuration to the Azure Functions out-of-proc-hosting model.
Validate your application locally before updating your deployment process and removing the redirect app setting.

After you have validated your application locally and updated your deployment process, you can remove the redirect app setting and allow the deployed app to move to the Azure Functions out-of-proc-hosting model when appropriate guidance has been published for your scenario.

Frequently Asked Questions

Q: How do I prevent my app from being migrated to the Azure Functions out-of-proc-hosting model?

The LOGICAPP_INPROC_REDIRECT setting is used to determine whether an app should remain on the current in-proc hosting model. By default, apps that do not have this setting will be moved to the Azure Functions out-of-proc-hosting model. Set the value to 1 if you need to prevent automatic migration until your app is ready.

Q: What happens if my app uses the NuGet deployment model?

If your app uses the NuGet deployment model, you should keep the redirect app setting in place for now. We will publish a separate communication when the required Logic Apps runtime package guidance and supported migration steps are confirmed for this scenario.

Q: Q: What happens if I accidentally remove the LOGICAPP_INPROC_REDIRECT = 1 from my configuration?

The LOGICAPP_INPROC_REDIRECT setting is used to determine whether an app should remain on the current in-proc hosting model. If you remove it by accidenty, your application will be moved to the Azure Functions out-of-proc-hosting model. But you can reset that behavior by reapplying the setting and restarting the application.

Q: Will there be a separate communication about .NET 10 support?

Yes. We will send a separate communication once we have confirmed the Logic Apps runtime and workflow version guidance for .NET 10 support.

Dynamic Connection Properties in Azure Logic Apps Standard

ShubhamSachdeva99 — Thu, 11 Jun 2026 13:20:10 GMT

Switching Built-in Connections at Runtime

The Problem

Imagine your organization has a single Logic App workflow used by multiple teams. Each team has its own SFTP server, database, or service bus namespace. Traditionally, you'd need separate workflows or hardcode a single connection — neither scales well.

The Solution

Logic Apps Standard supports dynamic connection names for built-in (service provider) connectors. Instead of hardcoding a connection name, you can use any workflow expression — trigger inputs, previous action outputs, parameters, or conditional logic — to determine which connection to use at runtime.

No designer support is available at this time — this works today via Code View.

How It Works

Define multiple connections in connections.json — one per team/environment/tenant
Resolve the connection name dynamically using any expression
Reference that expression in the connectionName field of your service provider action

The runtime evaluates the expression and resolves the connection from connections.json at execution time.

The Key Pattern

"serviceProviderConfiguration": { "connectionName": "@<expression-that-resolves-to-connection-name>", "operationId": "listFolder", "serviceProviderId": "/serviceProviders/Sftp" }

Instead of hardcoding "connectionName": "sftp", you provide an expression that evaluates to a connection key defined in connections.json.

What You Can Use as the Dynamic Value

Source	Example
Trigger body	@triggerBody()?['connectionName']
Trigger header	@triggerOutputs()['headers']['X-Connection-Name']
Conditional expression	if(equals(triggerBody()?['team'], 'teamA'), 'sftpTeamA', 'sftpTeamB')
Previous action output	@outputs('Resolve_Connection')
Workflow parameter	@parameters('defaultConnection')

Step-by-Step Example: Dynamic SFTP Connection

1. Define Connections in connections.json

{ "serviceProviderConnections": { "sftpTeamA": { "parameterValues": { "sshHostAddress": "@appsetting('SftpTeamA_HostAddress')", "username": "@appsetting('SftpTeamA_Username')", "password": "@appsetting('SftpTeamA_Password')", "portNumber": "@appsetting('SftpTeamA_PortNumber')", "rootDirectory": "@appsetting('SftpTeamA_RootDirectory')" }, "serviceProvider": { "id": "/serviceProviders/Sftp" }, "displayName": "SFTP - Team A" }, "sftpTeamB": { "parameterValues": { "sshHostAddress": "@appsetting('SftpTeamB_HostAddress')", "username": "@appsetting('SftpTeamB_Username')", "password": "@appsetting('SftpTeamB_Password')", "portNumber": "@appsetting('SftpTeamB_PortNumber')", "rootDirectory": "@appsetting('SftpTeamB_RootDirectory')" }, "serviceProvider": { "id": "/serviceProviders/Sftp" }, "displayName": "SFTP - Team B" } } }

2. Add App Settings

In your Logic App's Configuration → Application settings, add values for each connection:

Setting	Example Value
SftpTeamA_HostAddress	storageacctA.blob.core.windows.net
SftpTeamA_Username	storageacctA.localuserA
SftpTeamA_Password	(generated password)
SftpTeamA_PortNumber	22
SftpTeamA_RootDirectory	/uploads
SftpTeamB_HostAddress	storageacctB.blob.core.windows.net
SftpTeamB_Username	storageacctB.localuserB
SftpTeamB_Password	(generated password)
SftpTeamB_PortNumber	22
SftpTeamB_RootDirectory	/uploads

3. Create the Workflow (Code View)

{ "definition": { "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#", "actions": { "List_files_in_folder": { "type": "ServiceProvider", "inputs": { "serviceProviderConfiguration": { "connectionName": "@if(equals(triggerBody()?['team'], 'teamA'), 'sftpTeamA', 'sftpTeamB')", "operationId": "listFolder", "serviceProviderId": "/serviceProviders/Sftp" }, "parameters": { "path": "@triggerBody()?['folderPath']" } }, "runAfter": {} }, "Response": { "type": "Response", "kind": "Http", "inputs": { "statusCode": 200, "body": "@body('List_files_in_folder')" }, "runAfter": { "List_files_in_folder": ["Succeeded"] } } }, "triggers": { "When_a_HTTP_request_is_received": { "type": "Request", "kind": "Http", "inputs": { "schema": { "type": "object", "properties": { "team": { "type": "string" }, "folderPath": { "type": "string" } } } } } }, "contentVersion": "1.0.0.0" }, "kind": "Stateful" }

4. Test It

Send a POST request to the workflow trigger URL:

{ "team": "teamA", "folderPath": "/uploads" }

Change "team": "teamB" to route to the other SFTP server at runtime.

Multi-Step Resolution Example

For more complex logic — lookups, mappings, or multi-condition routing — resolve the connection in a prior action and reference its output:

{ "Resolve_Connection": { "type": "Compose", "inputs": "@if(contains(triggerBody()?['region'], 'eu'), 'sftpEurope', if(contains(triggerBody()?['region'], 'us'), 'sftpAmerica', 'sftpDefault'))", "runAfter": {} }, "Upload_File": { "type": "ServiceProvider", "inputs": { "serviceProviderConfiguration": { "connectionName": "@outputs('Resolve_Connection')", "operationId": "createFile", "serviceProviderId": "/serviceProviders/Sftp" }, "parameters": { "path": "/incoming/data.csv", "content": "@triggerBody()?['fileContent']" } }, "runAfter": { "Resolve_Connection": ["Succeeded"] } } }

Applicable Connectors

This pattern works with all built-in service provider connectors (type: "ServiceProvider"), including:

SFTP
SQL
Service Bus
Event Hubs
Azure Blob Storage (built-in)
SMTP
Azure Automation
And any other built-in connector

Limitations

Code View only — The designer does not render or edit dynamic connection names visually.
Built-in connectors only — Managed API connections (type: "ApiConnection") do not support this pattern.
Connection must exist — The resolved name must match a key already defined in connections.json. Connections cannot be created on-the-fly.
Case-sensitive — The expression output must exactly match the connection key in connections.json.

Tips

Use @appsetting() references in connections.json to keep credentials out of source control
Store passwords in Azure Key Vault referenced via app settings
Use meaningful connection names (e.g., sftpTeamA, sqlProd, serviceBusDev)
You can scale to any number of connections — just add entries to connections.json and corresponding app settings
Inline expressions like @if(...) work directly in connectionName — you don't always need a separate action

Productize, observe, version, and automate MCP servers in Azure API Management

anishta — Wed, 10 Jun 2026 03:18:33 GMT

Introduction

As organizations move from AI-assisted applications to agentic workflows, MCP servers are becoming a critical integration layer between agents, tools, APIs, data sources, and enterprise systems. Azure API Management already helps teams bring MCP servers under enterprise governance. But as MCP adoption scales, platform teams need more than basic exposure. They need a way to package MCP servers for the right consumers, understand tool usage in detail, manage changes safely, and automate configuration across environments.

These are familiar API management challenges — and the same patterns that organizations already use for APIs can now be applied more deeply to MCP servers. We are excited to announce new generally available capabilities for MCP server management in Azure API Management:

Add MCP servers to products to package and govern MCP capabilities for specific consumers
MCP tool observability to trace tool usage, logs, errors, and payload context
MCP server versioning to run multiple versions side by side and manage change safely
Management API and Bicep support to automate MCP server configuration as part of CI/CD workflows

Together, these capabilities extend MCP server management in Azure API Management and help make MCP servers first-class managed resources — productized, observable, versionable, and automatable.

Why MCP server management matters

MCP gives agents a standard way to connect with tools and external capabilities. That standardization is powerful, but it also introduces a new operational surface for enterprises.

Without a management layer, teams can quickly run into questions such as:

Which MCP servers are approved for use?
Who can access each server?
How do we expose MCP servers to different developer or agent audiences?
How do we monitor tool calls, latency, errors, and cost?
How do we run preview and production versions side by side?
How do we automate MCP server configuration across environments?

These are not just developer experience questions. They are enterprise governance questions. With Azure API Management, MCP servers can now be managed using the same core patterns organizations already use for APIs: products, subscriptions, policies, observability, versioning, and automation.

What’s new

1. Add MCP servers to products

Azure API Management products are a proven way to package APIs for consumption. With this release, you can now add one or more MCP servers to APIM products as well. This makes it easier to expose MCP capabilities to specific consumers, teams, applications, or agent experiences using familiar product-based governance.

For example, a platform team can create a product for internal agents that includes approved MCP servers such as:

Customer profile lookup
Order status retrieval
Knowledge base search
Ticket creation
Workflow automation tools

By adding MCP servers to products, teams can use familiar controls such as subscriptions, quotas, approval workflows, and access management to govern how MCP capabilities are consumed.

Why it matters: MCP servers are no longer isolated endpoints. They can be bundled, governed, and delivered as secure, consumable products.

2. MCP tool observability

As agents use MCP servers to discover and invoke tools, teams need more than basic traffic visibility. They need end-to-end trace context for each agent-to-tool interaction. With MCP observability in Azure API Management, teams can inspect key MCP-specific details, including:

Operation context: whether the request was a tools/list or tools/call operation
Session context: the MCP session ID through gen_ai.conversation.id
Client context: MCP client name and version
Protocol context: MCP protocol name and version
Server context: MCP server name and version
Access context: authentication type and API type
Tool context: tool name and tool type for tool invocation traces
Error context: error type and error message when a call fails
Payload context: tool invocation arguments and results when payload logging is enabled

This is especially important for agentic workflows, where a single user request may trigger multiple tool calls across different systems. With APIM, MCP traffic can be traced, inspected, and monitored using the same operational practices teams already use across their API estate.

Why it matters: MCP servers are not just accessible through APIM — they are observable. Platform teams can trace tool calls, inspect errors, and understand MCP usage with the same operational discipline they expect from managed APIs.

3. Expose multiple MCP versions

Enterprise teams need safe ways to evolve MCP servers over time. With MCP server versioning in Azure API Management, you can expose multiple versions of the same MCP server side by side. This allows teams to run a stable GA version while introducing a preview or next version for early adopters.

For example:

v1 can serve the majority of production traffic.
v2 can be exposed to a subset of consumers for testing.
Teams can monitor adoption, errors, latency, and behavior.
Once the new version is validated, v2 can be promoted with confidence.

This pattern is especially useful when MCP tools evolve, schemas change, new capabilities are added, or teams want to validate agent behavior before rolling changes out broadly.

Why it matters: MCP servers can now follow a safer lifecycle model: preview, validate, route, promote, and retire.

4. Management API and Infrastructure as Code

MCP server management also needs to work at enterprise scale. With Management API and Infrastructure as Code support, teams can provision and configure MCP servers programmatically through Azure API Management APIs and automation pipelines. This allows platform teams to define MCP server resources as part of repeatable deployment workflows using tools such as Bicep, Terraform, ARM, REST APIs, and CI/CD pipelines.

Teams can automate configuration for:

MCP server endpoints
Runtime and transport settings
Authentication configuration
Metadata and ownership
Versioning
Product association
Policies
Environment promotion

This is critical for organizations that need consistent MCP governance across development, test, staging, and production environments.

Why it matters: MCP server management can now be automated, reviewed, deployed, and governed like the rest of your API platform.

How these capabilities work together

Individually, each capability solves an important operational need. Together, they create a complete management model for MCP servers in Azure API Management. A platform team can:

Register or expose MCP servers through Azure API Management.
Package them into products for specific consumers.
Apply access controls, subscriptions, quotas, and policies.
Observe tool-level usage, latency, errors, traces, and cost.
Run multiple versions side by side.
Promote changes safely.
Automate deployment through APIs and Infrastructure as Code.

This brings the full API management playbook to MCP. Instead of treating MCP servers as unmanaged agent extensions, organizations can operate them as governed enterprise resources.

Example scenario

Imagine a company building internal copilots for customer support, sales, and operations. Each copilot needs access to different tools:

Customer lookup
Order history
Case management
Knowledge search
Refund workflows
Escalation workflows

With MCP and Azure API Management, the platform team can expose these capabilities as MCP servers and organize them into products. The customer support copilot can subscribe to the support product. The sales copilot can subscribe to the sales product. Early adopters can be routed to a preview version of a tool. Operations teams can monitor usage, errors, latency, traces, and cost. Platform teams can automate the entire setup across environments. The result is a more governed and scalable way to bring MCP-based tools into enterprise agent workflows.

Getting started

To get started with MCP server management in Azure API Management:

Create or identify an MCP server you want to expose through Azure API Management.
Add the MCP server as a managed resource in APIM.
Add the MCP server to an APIM product.
Configure access, subscriptions, quotas, and approval workflows.
Enable observability to monitor tool-level usage and traces.
Use versioning to manage preview and production versions.
Use the Management API or Infrastructure as Code to automate configuration.

Conclusion

MCP is quickly becoming an important standard for connecting agents to tools and enterprise capabilities. But for MCP to succeed in production, organizations need more than connectivity. They need governance, lifecycle management, observability, and automation. With these new MCP server management capabilities in Azure API Management, platform teams can manage MCP servers using the same trusted patterns they already use for APIs.

MCP servers are now first-class APIM resources — productized, observable, versionable, and automatable. We are excited to see how customers use these capabilities to build the next generation of governed, enterprise-ready agentic applications.

Logic Apps Aviators Newsletter - June 2026

WSilveira — Mon, 08 Jun 2026 19:10:51 GMT

In this issue:

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

Ace Aviator of the Month

June 2026's Ace Aviator: Florian De Langhe

LinkedIn: https://www.linkedin.com/in/floriandelanghe/

Florian De Langhe Lead Expert/Team Lead - Microsoft Integration @ delaware

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

Lead Expert/Team Lead for the Microsoft Integration team at delaware.
I have a wide range of responsibilities:
- People management
- Resource planning
- Design and operate our integration solutions at our customers, what we brand as "SmartLink".

Next to this, as many of us, I follow the latest AI news closely to keep up to date and try to stay ahead of the curve.

Can you give us some insights into your day-to-day activities?

I wear many hats so no two days look the same. That is also what keeps it interesting.

A typical day starts with reviewing resource planning across our active projects, followed by a technical design review for a new integration. Sprinkle some one-on-one coaching conversations and research into new technologies/features and you have my day.

The balance between People leadership and hands-on technical work is what I enjoy most.

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

I started out being an active member on the Microsoft Logic App forum 10 years ago. I remember going back and forth with Wagner through the forum posts trying to solve questions. Good times.

Integration is one of those disciplines where you're constantly connecting systems, teams, and ideas. What motivates me is seeing how members of our community across different companies and countries solve similar problems in completely different ways. The Aviators community has that right mix of deep technical knowledge and willingness to help each other out. Since discovering Integration and the Microsoft community, I basically never left.

Looking back, what advice do you wish you had been given earlier?

Document everything and treat documentation as a deliverable, not an afterthought.
Early in my career I saw documentation as the boring part that you do after the development work.
Now I see it as the leverage point. A well-written design document doesn't just help the next person understand what you built, it compounds. It feeds code generation, easier onboarding of new members and validation with your customers on what and how to build it.

What has helped you grow professionally?

Two things:
1) Always challenge yourself and your implementations; everything can be better, so I am always pushing myself to keep learning, stay up to date, and think about every idea/solution posted in this community—how it could improve my way of thinking or solutions that I am building/have built.
2) Focus on understanding the integration concepts and patterns. At the end of the day everything is a pattern; it is how you implement where we make the difference. So knowing the base layer itself helps a lot when building integration solutions.

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

To be able to control scaling of the workflow service plans more fine grained. Being able to control this would unlock a lot of use cases, especially for the combination of Logic Apps and Service Bus concurrency and throughput.

News from our product group

Write Logic Apps in C#: introducing the Logic Apps Standard SDK

This article introduces the Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk), a code-first way to define Logic Apps Standard workflows in C#. Developers compose workflows using a fluent builder with strongly typed triggers and actions, including both built-in and managed connector operations. The SDK preserves the existing runtime, connectors, monitoring, and run history while changing only the authoring experience. It supports control flow constructs, custom C# code steps, and run-after conditions for fault handling. Guidance covers getting started in VS Code, project layout, local F5 execution, and preview limitations such as no service provider connectors and work-in-progress managed identity support.

New AI gateway capabilities in Azure API Management

Azure API Management expands its AI gateway with a Unified Model API (preview) that lets clients use a single OpenAI-style format across providers, plus model aliases and discovery. GA updates include support for Anthropic and Google Vertex AI and content safety for MCP and Agent-to-Agent (A2A) traffic. Token observability now tracks cached, reasoning, and thinking tokens in Application Insights. Foundry import adds Anthropic API operations. A2A APIs reach GA with richer diagnostics and availability in classic tiers. Together, these features standardize governance, security, and observability for multi-model, multi-protocol AI applications.

🎉 Automation just became a team sport. Meet Azure Logic Apps Automation.

Azure Logic Apps Automation (public preview) is a new SKU that delivers a managed, SaaS-like experience for building and running workflow automations. It keeps the enterprise-grade Logic Apps engine while simplifying onboarding, collaboration, and governance with projects and applications, flexible permissions, and policy inheritance. The experience is AI-native with natural language authoring, first-class agents, tools via MCP, and managed sandboxes. It introduces a modern designer, draft mode, live run history, JavaScript expressions, elastic scale to zero, and knowledge-as-a-service integration—aimed at helping teams prototype quickly and operate securely at scale.

📢 Announcing Knowledge as a Service for Azure Logic Apps

Knowledge as a Service (public preview) provides a managed knowledge layer for Logic Apps that turns documents into a ready-to-use knowledge base without building a custom RAG pipeline. The service handles ingestion (parsing, chunking, embeddings) and retrieval (query rewriting, semantic search, ranking) and integrates with agentic workflows in Logic Apps Standard and the Automation SKU. On Standard, teams bring their own vector store and models; on Automation, the platform hosts them on behalf of the user. It supports Entra authentication and focuses on secure, grounded responses for agents and workflows.

Better Together: Build Agents in Microsoft Foundry, Automate them with Azure Logic Apps

This post outlines a combined stack for agentic applications: Microsoft Foundry for building and hosting agents, and Azure Logic Apps for invoking and orchestrating them. New capabilities let teams create or select Foundry agents directly from the Logic Apps designer, pair any trigger with an agent for autonomous execution, and expose 1,400+ Logic Apps connectors and entire workflows as agent tools. The approach enables agents to act across systems, handle long-running processes, and integrate with enterprise events, making deterministic workflows and AI-driven reasoning work together in production.

What's new in Azure API Management at Microsoft Build 2026

This roundup covers Build 2026 updates for API Management and API Center: GA for agent registration, assessment, and Git sync in API Center, plus a data plane MCP server for enterprise discovery. API Management adds GA support for JSON‑RPC agent‑to‑agent (A2A) APIs and extends content safety controls to MCP and A2A flows. Unified Model API enters preview to standardize client integration across model providers, and AI Gateway expands to Anthropic and Vertex AI with broader token metrics. Platform enhancements include multi‑domain and wildcard custom hostnames in v2 tiers and workspace support on the built‑in gateway.

Azure Connector Namespaces: managed integration for any Azure compute

Azure Connector Namespace (preview) offers a fully managed integration layer that brings the Logic Apps connector ecosystem to any Azure or self‑hosted compute without requiring a workflow engine. Apps call strongly typed SDKs for C#, Node.js, or Python to invoke actions and subscribe to triggers, while the namespace handles auth, token rotation, retries, throttling, and webhook delivery. It also projects connectors as MCP servers for agents, and supports hosted MCP servers like Playwright and Azure SQL. The post details building blocks, scenarios, security, governance, and preview limitations.

What's new in Azure Logic Apps at Microsoft Build 2026

This Build 2026 overview highlights Logic Apps Automation (public preview), GA for the Logic Apps MCP Server to expose workflows as MCP tools, direct invocation of Microsoft Foundry agents from Logic Apps, Knowledge as a Service, and code‑first development with the Logic Apps Standard SDK (Codeful Workflows). It also introduces a Migration Agent to help modernize from legacy platforms. The theme is making enterprise‑grade automation more accessible while preserving governance, reliability, and operational controls for production use.

Hosted MCP Servers in Connector Namespace (Preview)

Hosted MCP servers in Connector Namespace let teams deploy managed, enterprise‑ready MCP servers from a curated catalog in minutes. The platform handles deployment, scaling, authentication (inbound with Entra ID, outbound with managed identity or on‑behalf‑of), availability, and observability via Application Insights. Preview servers include Playwright for browser automation and Azure SQL via Data API Builder, enabling agents to use reliable tools without the overhead of self‑hosting. The post explains setup, benefits over self‑hosted servers, and areas of ongoing investment like catalog expansion and VNet support.

MCP Test Console and Git Repository synch in Azure API Center

Azure API Center adds a built‑in MCP Test Console in the developer portal and Git repository synchronization for MCP servers and other assets. Developers can validate MCP tools interactively on the Documentation tab and browse server tiles with endpoints and schemas. Git sync keeps the API Center inventory aligned with source‑controlled definitions, with secure access via Key Vault and managed identity. Together, these additions streamline discovery, testing, and governance of MCP assets across the enterprise.

Bringing all your Integration workloads to Logic Apps Standard

This post outlines Microsoft’s guided path for moving enterprise integration workloads—especially BizTalk—to Azure Logic Apps Standard. It introduces the open-source Logic Apps Migration Agent, which delivers an AI‑assisted, stage‑gated process across discovery, planning, baseline conversion, and continuous validation with human‑in‑the‑loop checkpoints. The workflow integrates with VS Code and GitHub Copilot, supports incremental “flow‑group” migration, and accommodates existing black‑box tests. The article also previews mission‑critical capabilities arriving for Standard and Hybrid (HL7, MLLP, Rules Engine, MSMQ, Oracle DB, flat‑file generation, Integration Accounts, and more), giving teams a repeatable, auditable modernization path with reduced risk.

Announcing Microsoft Host Integration Server 2028: Modern connectivity for IBM Mainframes Midranges

Host Integration Server 2028 (HIS 2028) is the next HIS release, delivered as a standalone SKU decoupled from BizTalk. It modernizes platform foundations (.NET 10) and, for non‑SNA features, introduces Linux support. New investments include Foundry integration for agent scenarios, REST APIs for DB2 and Transaction Integrator workloads, Entra ID and Azure Arc for hybrid management, a move to Visual Studio Code for designers, and alignment with newer IBM middleware. The post also lists product cleanup and deprecations (e.g., 32‑bit, WMI/WCF, BizTalk adapters), helping enterprises secure, govern, and operate host connectivity for years ahead.

Easy Auth Configuration for Logic App Standard through CI/CD

Enabling App Service Easy Auth on Logic Apps Standard can break run‑history views because SAS‑based runtime calls are blocked before the Logic Apps engine can validate them. This article explains two remedies: allow unauthenticated requests (so the runtime enforces its own auth), or keep Easy Auth strict and exclude runtime endpoints (e.g., /runtime/*) using authsettingsV2. It provides CI/CD‑ready approaches via ARM/Bicep templates or a post‑deployment REST API call, and highlights key settings such as requireAuthentication, unauthenticatedClientAction, excludedPaths, and allowedApplications. The guidance restores run‑history usability while maintaining enterprise authentication policies.

Run Javascript code on Agent Loop

Azure Logic Apps Agent Loop now supports a JavaScript code interpreter, extending earlier code‑execution support and enabling reliable computations, validations, and transformations alongside LLMs. The runtime executes generated or pre‑written code inside a V8 isolate using the isolated‑vm library, providing memory limits, timeouts, and failure isolation (not a full sandbox) to reduce blast radius. A worked example shows expense‑validation with agent tools orchestrated in a workflow. For Consumption, attaching an Integration Account provides isolated compute for the interpreter. The capability helps teams combine deterministic steps with agentic reasoning to deliver robust, auditable outcomes.

Bulk-configure diagnostic settings on Azure Logic Apps Consumptions

LA‑BulkDiag is a single‑file PowerShell script that bulk‑applies diagnostic settings across Logic Apps Consumption in a resource group. It inventories workflows, supports quick scopes (bare/all/pick), verifies destinations, auto‑renames on name collisions, and ships with 129 Pester tests. Presets cover logs, metrics, and workflow‑runtime categories; selection grammar enables non‑interactive runs suitable for CI. The post includes quick‑start commands and clarifies scope: it targets Consumption only (not Standard) and doesn’t configure Event Hub sinks. The result is faster, consistent observability at scale without repetitive portal clicks or accidental overwrites.

Clean up idle and always-failing Azure Logic App Consumption

LA‑CleanUp is a PowerShell utility that scans a subscription for Logic Apps Consumption workflows, classifying them as Idle (no runs in N days) or AlwaysFailing (runs in the window with zero successes). It can export candidates to CSV, then guide per‑item deletion with y/N/q prompts, reporting final counts. Under the hood, it uses OData filters and $top=1 queries for fast server‑side checks, caches an ARM token once, and intentionally avoids cross‑subscription operations. Scope notes: it doesn’t touch Standard workflows or API connections. The tool reduces noise, costs, and operational drag from abandoned or broken apps.

News from our community

Spec2Integration

Post by Balbir Singh

Spec2Integration proposes a spec-driven approach to building Azure Integration Services solutions. The open-source toolkit guides teams from a product brief through specification, modeling, contracts, mapping, and architecture to a deployable implementation targeting Azure Logic Apps, Functions, and related services. It includes governance gates for idempotency, observability, retries, and PII handling, plus a VS Code extension that visualizes pipeline status and the integration representation. Templates and tooling support greenfield projects and BizTalk migrations. The result aims to standardize repeatable steps, reduce failure modes, and accelerate delivery while keeping architectural control outside individual workflows.

Stateful Orchestration in Azure: When Logic Apps Break, and What to Do Instead

Post by Al Ghoniem, MBA

This article examines where stateful orchestration with Azure Logic Apps can fall short and how to design around those gaps. It differentiates execution state from business state and highlights common failure modes: long-running instances, retry-induced duplicates, partial completion across SAP/Oracle/APIs, lost correlation, and unowned DLQs. It then contrasts orchestration choices—stateful Logic Apps, Durable Functions, Service Bus–backed orchestration, and choreography—emphasizing idempotency, correlation, reconciliation, and compensation. The guidance steers architects toward a control and observability layer so production incidents can be traced, replayed, and recovered without relying on workflow run history alone.

Logic Apps Announcements at Microsoft Build

Video by Sebastian Meyer

This video recaps Logic Apps announcements from Microsoft Build with insights from a member of the product team. It highlights newly introduced capabilities and shares resources for deeper dives. Viewers get a concise overview of what’s new, why it matters for integration practitioners, and where to learn more. The discussion points architects toward practical use cases and next steps, making it a useful primer for anyone assessing roadmap impacts on existing or upcoming Azure Integration Services projects.

Logic Apps Standard vs. Consumption: Which Plan Should You Choose?

Post by Chiranjib Ghatak

The article compares Logic Apps Standard and Consumption, explaining differences in hosting models, pricing, networking, and development experience. It outlines when to pick each plan, noting Standard’s single-tenant model, VNet/private endpoints, built-in connectors, and local DevOps workflow, versus Consumption’s pay-per-execution model and simplicity for sporadic or low-volume workloads. It also covers performance trade-offs, stateful vs. stateless options available in Standard, and typical enterprise scenarios where Standard provides predictable costs and better throughput.

Azure Connector Namespaces: Managed Connectors Beyond Logic Apps

Post by Şahin Özdemir

This post introduces Azure Connector Namespaces and previews managed connectors for Azure Functions, extending the Logic Apps connector ecosystem to more compute services. It explains the motivation, how namespaces decouple connectors from workflows, and the benefits: reduced custom code, consistent authentication via managed identity, and reuse of Microsoft-managed integrations. A step-by-step walkthrough shows creating a namespace, adding a managed connector, and using the Azure Connectors .NET SDK in Functions, illustrating how teams can standardize connectivity while keeping business logic in code.

Stop working harder and start flowing smarter, with Logic Apps Automation

Post by Sonny Gillissen

Sonny Gillissen explores Logic Apps Automation, a new, governed experience for building enterprise automations. He explains the Project → Application → Workflow model, dedicated portal (auto.azure.com), and reusable Sandboxes for agent code. The post shows how the AI assistant can scaffold workflows from intent, with Knowledge sources to ground agents, while monitoring and analytics provide visibility. Benefits include familiar Logic Apps design, reduced operational overhead, and scale-to-zero. Current gaps are noted—OBO auth shift, occasional assistant syntax issues, managed vs. built‑in connector choices, no migration tooling yet, and pending VNet/private endpoint support.

Stop Using Static Filters! Automate DIXF Exports with Logic App

Post by Anitha Eswaran

Anitha Eswaran demonstrates how to make DIXF exports in D365FO dynamic using Azure Logic Apps and a small X++ customization. A custom OData action updates the DIXF Definition Group filter at runtime based on a parameter such as Customer Group. A Logic App triggered by a business event parses the input, stores the value, calls the OData action, invokes the standard ExportToPackage API, and then retrieves the download URL via GetExportedPackageUrl to fetch the ZIP with a time‑limited SAS token. Screenshots and code samples illustrate the end‑to‑end flow and implementation details.

Logic Apps Agent Loops: Master Class

Video by Stephen W Thomas

Stephen W Thomas compiles his full Logic Apps Agent Loop series into one master‑class video. It covers getting started with Agent Loop on Logic Apps Standard, a human‑in‑the‑loop pattern used to resolve failed code translations, interactive chat agents with secure website embedding via Easy Auth, and when to choose the Consumption tier for simpler, pay‑as‑you‑go deployments. The chaptered format lets viewers jump to relevant topics. The emphasis is on the orchestration pattern—agents that select and compose tools to achieve goals—offering a practical foundation for teams moving from deterministic workflows toward agentic automation.

Forget Sampling — This One host.json Setting Cuts Logic Apps Telemetry Costs by 80%

Post by Daniel Jonathan

This article tackles high Application Insights ingestion costs in Logic Apps Standard and shows a data‑driven path to reduce spend. Through a controlled experiment, it demonstrates that switching Runtime.ApplicationInsightTelemetryVersion to v2 in host.json delivers ~80% reduction without sacrificing troubleshooting. Further options include disabling dependency tracking (eliminates AppDependencies with the trade‑off of losing per‑call HTTP detail) and using adaptive sampling for marginal additional savings, while excluding exceptions. It also explains why some run‑level telemetry bypasses sampling and how to toggle sampling via an environment variable for short‑term diagnostics.

Production Is the Only Truth in Integration

Post by Marcelo Gomes

This piece reframes integration success through a production‑first lens. It argues that reliability emerges when systems are designed for failure as the norm, not the exception. The article urges separating orchestration from business logic—using tools like Azure Logic Apps for coordination and Azure Functions for rules and transformations—to keep retries safe and evolution predictable. It positions production‑readiness as a design concern, emphasizing idempotency, replay, observability, runbooks, and ownership. The practical outcome is reduced operational risk and cost, more predictable behavior, and greater business trust in automated processes.

DevUP Talks #05 – Logic Apps Tips & Tricks with Sandro Pereira

Video by Mattias Lögdberg

In this session, Sandro Pereira distills practical guidance from real projects to help teams build more resilient Logic Apps. Topics include applying environment‑specific timer conditions, deploying Logic Apps in a disabled state to control activation during releases, and using User‑Managed Identity with Azure Service Bus in Logic Apps Standard. The video focuses on patterns that improve reliability, security, and operational control across environments, offering actionable advice for developers and architects working in Azure Integration Services who want fewer surprises in production and a smoother deployment lifecycle.

Logic Apps: Service Bus with User‑Assigned Managed Identity

Post by Sandro Pereira

This best‑practices guide shows how to configure the Azure Service Bus connector in Logic Apps Standard to use a user‑assigned managed identity. Sandro Pereira explains why system‑assigned identities complicate CI/CD—RBAC can’t be fully declared until the identity exists—then demonstrates a pattern that keeps deployments reproducible. The approach uses app settings for the Service Bus namespace and identity resource ID, a custom serviceProviderConnections entry referencing those settings, and workflow actions bound to that connection. The result is secretless, declarative authentication that avoids RBAC timing issues across environments.

Logic App Consumption Bulk Failed Runs Resubmit Tool

Post by Sandro Pereira

Sandro Pereira introduces a small .NET Windows utility that lists and bulk resubmits failed Logic Apps Consumption runs. After authenticating to Azure, users supply the Logic App name, resource group and subscription. The tool can optionally filter by a date range, otherwise it returns up to 250 failed runs for fast triage. It targets a common pain point the portal features don’t fully streamline and includes a link to the GitHub source so teams can adapt or integrate it into operational workflows. A concise “one‑minute brief” outlines the problem and practical benefits.

Control the Initial State of Logic Apps Standard Workflows

Post by Sandro Pereira

This tip explains how to prevent Logic Apps Standard workflows from starting immediately after deployment—a common production risk. Instead of a state property in ARM/Bicep, the initial state is controlled via App Settings on the underlying App Service. By setting Workflows..FlowState to Disabled (in local.settings.json and/or app settings), teams ensure workflows deploy in a safe, non‑running state. The article outlines the rationale, differences from Consumption, and provides concrete examples and screenshots to adopt the practice across environments.

Write Logic Apps in C#: introducing the Logic Apps Standard SDK

WSilveira — Mon, 08 Jun 2026 21:52:53 GMT

The workflow you always wished you could write in code

If you build on Logic Apps Standard, you already know the deal: the runtime is excellent at the unglamorous parts of integration - connecting to systems, retrying, scaling, keeping run history you can actually debug. What you sometimes wanted was a different front door. You're a .NET developer. You live in C#, source control, and pull requests. And for a long time, authoring a workflow meant leaving all of that behind for a visual designer and a JSON file.

That's the gap the new Logic Apps Standard SDK closes. It lets you define Logic Apps Standard workflows in code - strongly typed, IntelliSense-guided C# - without giving up a single thing the runtime already does for you.

What is the Logic Apps Standard SDK?

The Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk) is a NuGet package that gives you a fluent, code-first way to build workflow definitions in C#. Instead of dragging actions onto a canvas, you compose a workflow with method chaining: a trigger, then the actions that follow it, all the way to a response.

Worth saying clearly, because people ask: this is a new way to define workflows - not a new runtime. The workflows you write with the SDK compile down to the same definitions and run on the same Logic Apps Standard runtime you use today. Same connectors. Same hosting. Same rich run history and monitoring. You're changing the authoring experience, not the engine underneath it.

Why this matters for developers

When your workflow lives in C#, it behaves like the rest of your code. A few things fall out of that almost for free:

Type safety and IntelliSense - connector operations, triggers, and outputs are discoverable as you type, and the compiler catches mistakes before you run anything.
Real source control and reviews - workflows diff like code, get reviewed in pull requests, and version alongside the services they orchestrate.
Familiar tooling - refactor, debug with F5, and lean on the .NET ecosystem you already know.
Extensibility on your terms — Compose your workflow declaratively with the fluent builder, then drop into plain imperative C# wherever a step needs logic that might be too complex to implement declaratively - loops, branching, a call into your own library, all encapsulated in a step of your workflow - without leaving the file or the language.

And it isn't limited to one style of work. The SDK covers both enterprise integration workflows - the connect-systems-and-move-data scenarios Logic Apps is known for - and agentic workflows, where a conversational or autonomous AI agent drives the steps. Both are first-class in the same SDK, built from the same building blocks.

There's one more angle worth calling out, because it's becoming hard to ignore: coding agents are simply better at writing imperative code than declarative JSON. And the reason is the same set of guardrails that helps you. Strong typing and a compilation step mean the code an agent produces is syntactically correct out of the gate — the type system and the compiler do the checking, so you don't have to. Layer unit tests on top and you've covered north of 90% of what matters; what's left is integration testing. Getting an LLM to the same level of accuracy against declarative JSON means building dedicated tooling to stand in for everything the compiler gives you for free. With code-first workflows, those guardrails are just there — which makes this a natural fit for an agent-assisted way of building.

Getting started

Everything here lives in the Logic Apps extension for VS Code. You'll want the Logic Apps Standard VS Code extension version 5.961.10 or later, which includes all the components you need to create code first workflows. Beyond that, the prerequisites are the ones you'd expect - VS Code with the Logic Apps extension, an Azure subscription you can create resources in, and a working comfort with C# and .NET.

From a clean start, you're a handful of steps from a running workflow:

Create the workspace — launch the Logic Apps extension and choose Create new Logic Apps workspace. Pick a folder, name the workspace and project, and when prompted for the workflow type, choose Logic Apps codeful - that's the code-first option that uses the SDK.
Pick a workflow kind - name your first workflow and choose how it runs: Stateful, Autonomous agents (Preview), or Conversational agents (Preview). The agent options are where the agentic scenarios live.

Enable connectors - when prompted, select Use connectors from Azure, choose your subscription and resource group, and pick Connection Keys for authentication. Managed identity is still in development, so connection keys are the way in for now.
Find your way around - the project opens with Program.cs, which builds and starts the host, plus a workflow file (like workflow1.cs) where your trigger and actions are defined. The SDK compiles those definitions and runs them on the Logic Apps runtime.
Run it - press F5 (or right-click Program.cs and pick Overview). The runtime starts locally and an overview page opens where you can fire triggers, watch run history, and inspect inputs and outputs.

That last part is worth dwelling on: run history for SDK workflows uses the same rich visual view as designer-built ones. You author in code, but you monitor and troubleshoot exactly as you always have.

A look at the capabilities

Connectors and triggers

Every workflow starts with a trigger and runs a series of actions. The SDK exposes both through two entry points - WorkflowTriggers and WorkflowActions - each split into BuiltIn and Managed.

Built-in triggers and actions run directly in the runtime: HTTP request, recurrence, and the conversational agent trigger; actions like Compose, HTTP, Response, and custom code.
Managed connectors give you the full Logic Apps connector catalog - Service Bus, SharePoint, SQL, and hundreds more - typed and ready to call.

The managed surface is generated from the same connector definitions the designer uses, so the operations you know are right there:

// Built-in trigger var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // Managed connector action — full catalog, strongly typed var getItems = WorkflowActions.Managed .Sharepointonline("sharepoint") .GetItems( dataset: () => "https://contoso.sharepoint.com", table: () => "orders-list-id") .WithName("GetOrders");

The fluent API streamlines the definition

This is where it comes together. You compose a workflow by chaining operations with .Then(...). The shape of your code mirrors the shape of your workflow - read it top to bottom and you read the execution path.

trigger .Then(validateOrder) .Then(getOrders) .Then(sendResponse);

Control flow is part of the same fluent model. Built-in structures like Condition (if/else) and ForEach - along with Switch, Until, Scope, and Terminate - are just actions you chain in, each taking a small factory for the branch or loop body:

var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => order.Total > 1000, trueBranch: () => requireApproval, falseBranch: () => autoApprove ).WithName("CheckOrderValue");

And ForEach takes the collection to iterate and a factory that builds the body for each item:

var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => order.LineItems, actions: (item) => new WorkflowBuiltInActions() .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems");

Need parallel branches that fan back in? The same Then pattern handles branching and join - no JSON wiring, no run-after blocks to hand-edit.

Extending workflows with custom code

Some logic doesn't belong in a connector or an expression - it's just code. The CustomCode action lets you drop a real C# method into the middle of a workflow. It receives a WorkflowContext, so you can read the trigger payload or any earlier action's results and return a strongly typed value the next step can use:

var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var trigger = await context.GetTriggerResults(); var order = await context.GetActionResults("GetOrders"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder");

That's the escape hatch that keeps you in flow: when a step needs custom transformation, validation, or a call into your own libraries, you write a method instead of bending an expression to do something it was never meant to.

Handling failures: try/catch with run-after

Real workflows have to deal with things going wrong, and the SDK gives you the same try/catch shape Logic Apps has always had - expressed in code. The .Then(...) overload takes a FlowStatus[] run-after condition, so a handler runs only when the step before it ends in a status you name. Wrap the risky work in a Scope (your try), then chain a handler that runs after it Failed or TimedOut (your catch):

var tryProcess = WorkflowActions.BuiltIn.Control.Scope(() => callPaymentApi.Then(saveOrder) ).WithName("ProcessPayment"); var handleFailure = WorkflowActions.BuiltIn .Compose(inputs: () => "Payment failed — compensating") .WithName("HandleFailure"); trigger .Then(tryProcess) .Then(handleFailure, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut });

The status set is the whole vocabulary: Succeeded, Failed, Skipped, and TimedOut. Combine them however a step needs - a cleanup action that should run no matter what can list every status; a finally is just the union.

The same idea scales to fan-in. When several parallel branches converge, the per-predecessor RunAfter overload lets the join wait on each branch independently - so you can require some to succeed and tolerate others failing:

leftChain .Join(rightChain) .Then(merge, runAfter: new[] { new RunAfter(leftChain, FlowStatus.Succeeded), new RunAfter(rightChain, FlowStatus.Succeeded), });

Putting it together

Here's a small but complete shape - an HTTP-triggered order workflow that validates input, branches on order value, loops over line items, runs custom code, and replies. The core steps live in a Scope so a single failure handler can catch anything that goes wrong, and a clean reply only runs when the work succeeds. Notice it's all one readable chain:

namespace LogicApps { using Microsoft.Azure.Workflows.Sdk; using Microsoft.Azure.Workflows.Sdk.Connectors.Msnweather; using System.Net; public class OrderWorkflow : IWorkflowProvider { /// <summary> /// Gets the HTTP request/response workflow definition. /// </summary> public FlowDefinition[] GetWorkflows() { // --- Trigger ---------------------------------------------------- var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // --- Managed connector action (full catalog, strongly typed) ---- // Reused verbatim from the confirmed stateful1.cs pattern. var getWeather = WorkflowActions.Managed.Msnweather("msnweather").CurrentWeather( location: () => "98058", units: () => unitsInput.Imperial).WithName("GetWeather"); // --- Custom code: real C# in the middle of the workflow --------- var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var triggerResults = await context.GetTriggerResults(); var weather = await context.GetActionResults("GetWeather"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); // --- ForEach over a collection (control flow via .Control) ------- var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => trigger.TriggerOutput.Body["lineItems"], actions: (item) => WorkflowActions.BuiltIn .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); // --- Condition (if/else) (control flow via .Control) ------------ var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => true, trueBranch: () => processLines, falseBranch: () => WorkflowActions.BuiltIn .Compose(inputs: () => "Auto-approved").WithName("AutoApprove") ).WithName("CheckOrderValue"); // --- Scope groups the core steps so one handler catches failures - var processOrder = WorkflowActions.BuiltIn.Control.Scope(() => checkTotal .Then(getWeather) .Then(enrich) ).WithName("ProcessOrder"); // --- Responses -------------------------------------------------- var ok = WorkflowActions.BuiltIn.Response( responseBody: () => "Order processed").WithName("Reply"); var failed = WorkflowActions.BuiltIn.Response( statusCode: () => HttpStatusCode.InternalServerError, responseBody: () => "Order failed").WithName("ReplyFailed"); // --- Assemble --------------------------------------------------- // Happy path runs after the Scope Succeeded; the handler runs after // Failed or TimedOut. trigger .Then(processOrder) .Then(ok, runAfter: new[] { FlowStatus.Succeeded }) .Then(failed, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); return new[] { WorkflowFactory.CreateStatefulWorkflow("OrderWorkflow", trigger) }; } } }

That last stretch is the best-practice shape in miniature: the happy-path Reply runs only after the Scope Succeeded, while a separate handler catches Failed or TimedOut and returns a 500 - no exception plumbing, just run-after conditions.

You implement IWorkflowProvider, hand your trigger graph to WorkflowFactory as a stateful, stateless, or agent workflow, and the host registers it. Run it with F5 and the Logic Apps runtime starts locally - same as any Standard project.

Before you build: preview realities

I'd rather you go in clear-eyed. While the SDK is in public preview, keep these in mind:

Service Provider connectors aren't supported yet - that connector type is coming in a future release.
Dynamic schemas aren't supported - support is planned.
Custom code supports callback methods only - inline lambdas aren't available in this version.
Define and name actions before referencing them - name an action before using it as a dependency elsewhere.
Managed identity authentication is in development - use connection keys for connectors in the meantime.

Try it, and tell us what you think

If you've ever wanted your workflows to live where the rest of your code lives - in C#, in source control, in your pull requests - this is for you. Install the Logic Apps extension for VS Code, create a Logic Apps codeful project, and build your first workflow in code.

This is a preview, which means your feedback genuinely shapes where it goes - which capabilities come next, where the rough edges are.

Bring issues, feature requests and feedback to our GitHub page. I read it. Let's make code-first workflows something you actually want to use.

New AI gateway capabilities in Azure API Management

budzynski — Tue, 02 Jun 2026 20:48:15 GMT

Multi-model, multi-protocol AI applications are quickly becoming the norm. Teams are mixing OpenAI, Anthropic, and Vertex AI models, exposing tools through MCP, and wiring agents together with A2A. As that surface grows, so does the work of keeping it secure, observable, and consistent.

Our ongoing strategy for the AI gateway capabilities in Azure API Management centers on that problem: providing one place to manage models, MCP tools, and agents, no matter which provider or protocol is behind them. The updates below are the latest steps in that direction.

Unified Model API (preview)

The headline change in this release: the Unified Model API lets clients speak one API format — OpenAI Chat Completions — while API Management transforms requests to the backend provider, whether that's a model using OpenAI Chat Completions or Anthropic Messages API.

By centralizing model access behind a single API layer, you can:

Standardize on a single API format for clients, independently from the formats used by backend models.
Unify observability, security, and governance with policies that apply across model providers.
Configure failover across model providers.
Decouple client-facing model names from backend model names using aliases.

Learn more about the unified model API.

Model aliases

Model aliases give clients a stable, provider-neutral name to use when calling a model. By assigning an alias like gpt or claude-sonnet, you decouple the client-facing model name from the actual backend deployment.

That makes a few common operations a lot easier:

Upgrading a model. Update the alias target to point at a new version — no client code changes required.
A/B tests. Shift traffic between backends behind the same alias using API Management's load balancing capabilities.
Vendor swaps. Replace one provider with another without touching application code.

Model discovery

Developers can discover available models by calling the /models endpoint of the Unified Model API. API Management returns the list of model aliases, so apps and tools can adapt to what the platform team has published — without out-of-band documentation.

Anthropic and Vertex AI models (GA)

AI gateway policies and observability now work with Anthropic and Google Vertex AI models, alongside the providers we already support.

You can:

Apply runtime policies such as content safety, token limits, and semantic caching to Anthropic and Vertex AI traffic.
Collect logs, traces, and metrics for these models in the same place as the rest of your AI traffic.

If you're running a multi-provider setup, you no longer need a separate governance story for each vendor.

Learn more about AI gateway capabilities in API Management.

Anthropic API operations in Microsoft Foundry import

When you import a Microsoft Foundry resource as an API in Azure API Management, the import now creates operations for Anthropic APIs alongside the existing model APIs. In a few clicks, you can stand up an API that mediates traffic to Foundry models using either the OpenAI or Anthropic API format — no manual operation definitions needed — and then apply the same policies, security, and observability you use for the rest of your AI traffic.

Learn more about Microsoft Foundry import.

Token metrics for additional token types (preview)

Token tracking used to stop at prompt, completion, and total tokens. Modern models add cached, reasoning, and thinking tokens, which can make up a significant share of token consumption, cost, and latency.

API Management now logs metrics for these additional token types into Application Insights, across API formats (OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages API) and providers (Microsoft Foundry, OpenAI, Amazon Bedrock, Google Vertex AI, and others).

With richer signals, your cost dashboards, budget alerts, and capacity planning can actually reflect how today's models behave.

Learn more about token metrics.

Content safety for MCP and A2A (GA)

The llm-content-safety policy now covers MCP and A2A traffic in addition to LLM traffic. That includes MCP tool-call arguments, MCP response text, and A2A payloads.

A couple of related improvements:

llm-content-safety can now be configured directly as an outbound policy.
Two new attributes — window-size and window-overlap-size — let you tune how messages exceeding the Azure Content Safety limit of 10,000 characters are chunked and forwarded for validation, balancing detection sensitivity with Azure Content Safety call volume.

The result is one consistent safety policy across LLM, MCP, and A2A flows instead of stitching together custom filters per protocol.

Learn more about the content safety policy.

A2A APIs (GA)

Support for Agent-to-Agent (A2A) APIs in API Management is now generally available. Agent APIs can now be governed with the same policies, identity, and observability you use for the rest of your APIs.

What you can do with A2A APIs in API Management:

Mediate JSON-RPC runtime operations to your agent backend with full policy support — including the content safety improvements above.
Expose and manage agent cards, automatically transformed by API Management to represent the managed agent API.
Log traces to Application Insights using OpenTelemetry GenAI semantic conventions for deep correlation between API and agent execution traces.

What's new in GA, on top of the preview:

Available in classic tiers, in addition to v2 tiers — bring A2A governance to existing API Management resources without migrating tiers.
Richer diagnostic logging for A2A APIs, giving more actionable telemetry for monitoring and troubleshooting agent traffic.

Learn more about A2A support in API Management.

Related: Bring Your Own Model in Foundry Agent Service (GA)

Last month, Bring Your Own Model (BYOM) in Foundry Agent Service went GA. BYOM lets enterprise teams route Foundry agent model calls through their own infrastructure — typically for compliance, governance, or to reuse an existing model gateway.

This pairs naturally with the AI gateway capabilities in Azure API Management. Put API Management in front of your models, apply the policies and observability described above, and have Foundry agents call through it — getting consistent governance for both your direct AI traffic and your agent workloads.

Get started

Together, these updates make Azure API Management a more complete AI gateway: consistent governance, security, and observability across models from various providers, MCP tools, and agent interactions.

Some of these features are still rolling out. They will first become available in v2 tiers of API Management and in the AI release channel for classic tiers, then continue rolling out to the rest of classic tier resources over the following weeks.

Get started with the unified model API or explore the AI gateway capabilities in API Management.

🎉 Automation just became a team sport. Meet Azure Logic Apps Automation.

DivSwa — Tue, 02 Jun 2026 19:45:58 GMT

Low barrier to entry. Built for production.

Now in Public Preview

There's a moment that plays out in almost every organization right now. Someone closest a business problem - a retail ops lead, a finance analyst, a security analyst looks at a repetitive process and thinks, this should just run itself. For most of computing history, turning that idea into reality required specialized skills, significant setup, and engineering resources that were often focused elsewhere.

AI is changing that. Today, people can describe what they want in natural language and watch working solutions take shape. The bottleneck is no longer generating an idea for automation. It's turning that idea into something secure, governed, and reliable enough to run in production. The demos are everywhere. The question organizations are increasingly asking is the harder one: which of these can we actually run in production?

That's exactly the shift we built for.

Today at Microsoft Build we're introducing Azure Logic Apps Automation, a new Logic Apps SKU that delivers the experience of a modern SaaS product for creating and running workflow automations. It makes it easier for teams to get started quickly while preserving the security, governance, reliability, and scale organizations expect from Azure. It's open to builders of every kind, available now in public preview at https://auto.azure.com.

New experience, same enterprise engine

The goal was straightforward: simplify the experience of building and running automations without compromising the enterprise foundation underneath.

Logic Apps Automation provides a managed experience where compute, model endpoints, knowledge services, and execution environments are available out of the box. Teams can focus on solving business problems rather than assembling infrastructure and services.

We also introduced a dedicated SaaS experience designed around productivity and collaboration. Administrators establish governance and policies, while builders can quickly begin creating workflows without requiring deep Azure expertise.

"The redesigned experience lets me build AI-based solutions in record time. This platform will serve as the glue in most modern solutions.", Mick Badran, Founder & Director at SolveIT.Today [LA Automation Early Adopter]

What we kept is just as important. Logic Apps Automation is built on the same Azure Logic Apps platform organizations trust today. The reliability, scale, security, governance, and operational maturity remain the foundation. The experience is simpler, but the platform underneath is the same proven technology customers rely on every day.

Low barrier to entry. Built for production. We mean both halves of that sentence.

Build like a startup, ship like an enterprise

Building an automation is only part of the full application journey. As solutions move from experimentation to production, along with simple experience, organizations need security, governance, networking, identity, and operational controls to ensure those automations can be trusted at scale.Logic Apps Automation is designed for both realities.

On the build side, it's fast to get started. Login and start building workflows; stay on a single canvas throughout the experience: use AI assisted workflow development, use visual workflows when they’re the right fit, and drop into code the moment you need additional control. No switching tools, no handoffs, no separate infrastructure to manage.

On the production side, organizations get the capabilities they expect from an enterprise platform, on day-0: isolated compute, virtual network integration and private endpoints, identity, role-based access, audit logging, and governance policies.

For many automation tools, becoming "enterprise-ready" is something that happens later. With Logic Apps Automation , production-readiness is part of the foundation.

Built for how teams actually work

Making automation easier for builders shouldn't create additional complexity for administrators.

Organizations already have established governance boundaries, ownership models, and operational processes. Logic Apps Automation is designed to align with those realities through a simple two-level hierarchy of Projects and Applications. Project sits at the top and act as your security and governance boundary; inside each project you run one or more Applications.

Admins and project owners set networking policies, connector policies, sandbox configuration, and approved AI models once, at the project scope and every application inherits them. Builders get a wide-open space to create. Admins get a firm line around it. Nobody has to choose between the two.

Flexible permission management for individuals and teams

The permission model is also designed to match how teams collaborate:

A private space for an individual. To give a single user a place to run their own automations with a privacy boundary around personal resources such as their email account - create an application that only that individual can access.
A shared space for a team. To support an automation that several people co-develop and operate together, add multiple users to the application so they can build, run, and maintain it collectively.

The same model accommodates both access patterns, giving builders clear control over the scope of each application and who can work within it.

AI-native, not AI-retrofitted

Logic Apps Automation is designed for a new generation of business processes that combine workflows, AI agents, enterprise systems, and human decision-making.

It starts with how you build. A built-in AI Assistant turns plain language into working automation. You describe what you want and it drafts the workflow, configures actions, writes expressions, and generates inline code, then helps you edit the same way. You can author at the level of a single step or an entire end-to-end flow. This is the thing that opens the platform to *every* developer: the person closest to the problem can describe it and get something real, while pros stay in control and drop to code whenever they want.

"With the power of AI, automations just got on steroids! Simply tell it what you need, explain the intent, et voilà! Love it.", Sonny Gillissen,

Integration Architect at Rubicon Cloud Advisor [LA Automation Early Adopter]

Agents are first-class

Agents are first-class, and we meet you where you are with three ways to integrate them:

Agent-loop orchestration. If you're already using Logic Apps actions as tools inside an agent loop, that pattern carries forward. Your actions are callable tools the agent can invoke, so you keep orchestrating the way you always have.
Foundry agents. Connect to an existing Microsoft Foundry Hosted or Prompt Agent or create a new one right from the canvas. The platform handles the wiring, and your workflow calls the agent, gets results back, and keeps moving.
Managed sandbox for agent harnesses. Bring a well-known agent harness, like GitHub Copilot and run it in a managed, isolated sandbox. We take care of the compute, the isolation, native shell access, and your GitHub repos as first-class context; you just define the business logic.

Then orchestrate all of these inside a larger workflow, right next to traditional rule-based actions, on a single canvas. Deterministic and agentic, in one place.

A few capabilities that make this especially powerful:

Sandboxed agent harnesses. Run agent harnesses such as GitHub Copilot in a managed, isolated sandbox with shell execution, skills, and GitHub repos as first-class context, without operating any of that infrastructure yourself.
Tools and MCP. Turn any of the 1400+ connectors into a tool or expose any workflow as an MCP server that any compatible agent can call. No code required.
Knowledge as a Service. Drop in your documents and the platform handles ingestion, chunking, embeddings, and retrieval. No RAG pipeline to build, no vector store to operate; just grounded answers.
Any model, anywhere. Plug in whatever fits the job: frontier, open-source, fine-tuned, or local. You're never locked in.

"Azure Automation closes the gap between integration and intelligence with agents as first-class workflow actions, grounded in your own data, executing in isolated sandboxes, all within the same canvas where your triggers and connectors live. Excited to see the evolution.", Sagar Sharma, Enterprise Solution Architect at i8c NL [LA Automation Early Adopter]

What's new in this release

Logic Apps Automation introduces several new capabilities designed to help teams build, deploy, and govern AI-powered automations:

Zero-friction onboarding. Get from Sign-in to first workflow in minutes, with managed infrastructure and enterprise capabilities available from the start.
A new designer. Modern designer with single pane experience to build and monitor workflows, draft-mode for workflows for easy iterations, instant code-to-workflow synchronization when you want to work in code-view, run history you can stream live, and so much more
Natural language authoring. Describe workflows in plain language to create and edit them, with AI assistance in the designer.
More powerful agents. Three ways to bring agents into a workflow; agent-loop orchestration, Foundry Hosted Agents, and well-known harnesses like GitHub Copilot running in a managed, isolated sandbox with shell access and GitHub repos as context.
Knowledge as a Service. A managed knowledge layer that turns your documents into a ready-to-use knowledge base; no RAG pipeline required.
JavaScript expressions. Write inline JavaScript to transform data and express logic without leaving the designer; no domain-specific language to learn.
Projects and applications. A two-level governance hierarchy that gives admins a clear boundary and builders room to create. A permission management model that accommodates different level of access patterns, giving builders clear control over the scope of each application and who can work within it.
Elastic scale, including to zero. Workflows scale up automatically when load arrives and scale all the way down to zero when there's no work to do. You pay only for the vCPU-seconds you actually use.

Built to scale

Logic Apps Automation scales automatically with demand, from idle workloads to business-critical processes. Customers pay only for the resources they use, without per-seat licensing requirements or infrastructure management overhead. When workflows aren't running, you're not paying for compute. When demand increases, the platform scales with you.

Pricing

Logic Apps Automation uses a consumption-based pricing model, so you pay only for what you use. Pricing is based on a small managed-environment fee, workflow execution, and optional services such as AI model usage, knowledge, sandboxes, connector calls. There is no annual commitment, no per-seat license, no quota cliff. When your workflows sit idle, you pay nothing for compute. More details to follow soon.

What's available, and what's next

Logic Apps Automation is available today in public preview, with an intial set of regions today, with more rolling out over the coming weeks. Here is the list of regions its available today:

East Asia
Sweden Central
Australia East
North Central US
UK South
Southeast Asia
West US

Coming Soon

We're continuing to expand the platform with additional AI and enterprise capabilities, including:

Foundry Hosted Agents. Create or Invoke Foundry Hosted Agents directly inside your workflows.
Foundry Prompt Agents. Create/Invoke Foundry prompt directly inside your workflows.
Hosted Models. Managed model endpoints provided for you; no keys or infrastructure to bring.
Inline Python. Write inline Python alongside JavaScript when you need it.
Bring your own container image. Run your own code in sandboxes; for example, orchestrate a Python ETL job from within a Logic Apps workflow.
VNet support and private endpoints.
Custom connectors and more Automation templates. Build custom connectors, start from a growing library of templates, and set project-level policies on connectors and more.

Get started

Whether you're automating a business process, orchestrating AI agents, integrating enterprise systems, or building entirely new AI-powered experiences, Logic Apps Automation provides a simpler path from idea to production.

Start building today at https://auto.azure.com
Read the docs at http://auto.azure.com/docs
Watch the announcement session at Microsoft Build 2026.
See it live at the Integrate conference, June 8–9.

📢 Announcing Knowledge as a Service for Azure Logic Apps

DivSwa — Wed, 03 Jun 2026 15:32:29 GMT

Now in Public Preview

Turn your documents into a ready-to-use knowledge base without custom RAG pipelines.

Today at Microsoft Build 2026, we are announcing the Public Preview of Knowledge as a Service for Azure Logic Apps. It is a managed knowledge layer that transforms your documents into a ready-to-use knowledge base, removing the need to build custom Retrieval-Augmented Generation (RAG) pipeline, operate a vector store, or maintain retrieval logic. The result is grounded, accurate answers for the agents and workflows you are building today.

Most organizations hold a significant amount of institutional knowledge such as HR policies, product manuals, support runbooks, contracts, and specifications distributed across documents, spreadsheets, and internal systems. The challenge has rarely been the availability of content. It has been making that content reliably and accurately retrievable by AI agents and workflows.

Until now, addressing this challenge required building a RAG pipeline in-house. As any team that has implemented one can attest, a production-grade RAG pipeline involves substantial engineering effort and ongoing operational overhead.

The complexity of building RAG in-house

A production-grade RAG pipeline is not a single component. It is a set of interdependent systems that must be designed, integrated, and maintained:

Ingestion: parsing multiple file formats, chunking content appropriately, summarizing, and generating embeddings.
Storage: provisioning a vector database, defining indexing policies, and tuning for cost and performance.
Retrieval: rewriting queries, vectorizing them, executing semantic search, and returning the most relevant chunks to the model.
Operations: monitoring upload status, handling failures, managing credentials, and maintaining security.

Each component represents a meaningful engineering investment. Together, they constitute a platform — one that diverts engineering capacity away from the business problems teams set out to solve.

Introducing Knowledge as a Service

Knowledge as a Service (also referred to as Knowledge Base as a Service, or KBaaS) is a managed knowledge layer built into Azure Logic Apps that turns your documents into a ready-to-use knowledge base, without requiring you to build or operate a RAG pipeline.

You provide the documents, and the platform manages the remainder of the process, both ingestion and retrieval, end to end. Built directly into Logic Apps, KBaaS provides an abstraction over the underlying vector store and AI models, enabling your workflows to consume structured, semantically searchable knowledge through a single connection.

A knowledge base is a logical container that organizes related sources for a given domain. For example, an "HR Policies" knowledge base might hold all relevant HR documents. You create the knowledge base, upload your files, and attach it as a tool that your agent can call.

How it works

KBaaS is built around two managed pipelines.

Ingestion pipeline. When you upload a knowledge source, the service automatically parses, chunks, summarizes, and vectorizes the content, then stores the results, with no manual preprocessing required. The current preview supports a broad range of formats out of the box: DOC, DOCX, HTML, MD, PDF, PPT, PPTX, TXT, XLS, and XLSX. Each upload provides a progress status and a clear Completed or Failed result.

Retrieval pipeline. When your agent queries the knowledge base, the service rewrites the query where beneficial, generates a vector representation, executes a semantic search, and returns the most relevant chunks to the language model for response generation. Query planning, vector search, and ranking are all handled by the service.

The outcome is that your agents receive accurate, context-rich answers grounded in your own content, without requiring you to author retrieval logic.

Built for agentic workflows

KBaaS is available in Azure Logic Apps Standard, where it integrates directly with agentic workflows. Once a knowledge base has been created, it appears as a capability that can be attached to an agent loop. From there, the agent automatically queries the knowledge base to retrieve semantically relevant information from your uploaded documents at the point it is needed, as part of completing a task.

Getting started involves three steps:

Create the knowledge base connection - associate your vector store and your completions and embeddings models.
Add knowledge sources - upload files into a knowledge base, optionally organized into groups.
Add the knowledge base as a context - select it from the agent node so your agent can begin retrieving.

The platform provisions and manages the required databases, containers, and indexing policies on your behalf, removing the burden of operating the underlying storage and search infrastructure.

Two SKUs to consume it - Standard or Automation

This feature is available across Logic Apps SKUs, with some differences in how you setup and manage them.

Logic Apps Standard — bring your own resources. On Standard SKU, the model operates on your own Cosmos DB vector store and AI models, KBaaS integrates with them directly. You connect your existing resources, and the platform manages the complete ingestion and retrieval pipeline on top of them. This approach retains full control over your data and models while removing the need to build and maintain the RAG pipeline.

Logic Apps Automation SKU — bring only your documents. On the Automation SKU, KBaaS operates on a hosted-on-behalf-of model, in which the platform provisions and manages both the underlying vector store and the AI models. There is no Cosmos DB to provision, no embeddings or completions model to deploy, and no connections to configure. You upload your documents and attach the knowledge base to your agent, and the entire knowledge layer, including the supporting infrastructure is fully managed for you.

This delivers the same managed knowledge experience with the maximum degree of abstraction, providing the most direct path from source documents to a working, agent-ready knowledge base.

Secure by design

KBaaS supports authentication through Microsoft Entra ID using either a managed identity or an API key. We recommend managed identity wherever possible. It is the most secure option and eliminates the need to manually provision and rotate credentials, secrets, or access keys.

Available today in Public Preview

This initial release focuses on the most common starting point: uploading unstructured documents. Additional capabilities are planned, including support for more knowledge sources, richer ingestion (such as image parsing, semantic chunking, and multimodal embeddings), configurable retrieval settings, access checks during retrieval, and more.

Knowledge as a Service is available now in Public Preview. Provide your documents and give your agents a knowledge base that is ready to use, without building or operating a RAG pipeline.

Read the MS Learn docs to get started
Check out the demo below

Better Together: Build Agents in Microsoft Foundry, Automate them with Azure Logic Apps

DivSwa — Tue, 02 Jun 2026 19:33:15 GMT

One agentic stack: Foundry brings the intelligence; Logic Apps brings the automation and orchestration.

The promise of agentic AI is not simply more capable chat. It is autonomous work that advances real business processes. To achieve this, agents require two things: a place to be built with the appropriate models, instructions, knowledge, and guardrails and a place to be invoked and orchestrated, with triggers, workflows, and connections to the systems where work actually occurs.

Today, we are announcing a significantly improved experience that brings these two platforms together: Microsoft Foundry and Azure Logic Apps. Together, they form a single agentic stack. Foundry provides the intelligence, and Logic Apps provides the automation and orchestration.

What's new

This release introduces a set of updates that taken together, brings a really better together experience to build and automate AI

A streamlined experience to create and invoke Foundry Agents from Azure Logic Apps. You can now move from having an agent to running that agent inside a production business workflow in a few steps. You can author, configure, and call a Foundry Agent directly from the Logic Apps designer, with no custom integration code required.

Run Foundry Agents autonomously with Logic Apps triggers. This capability is what enables embedding Foundry Agents in workflows. A chat-bound agent runs only when a user types a message; an autonomous agent runs when the business requires it. With this release, you can pair any Logic Apps trigger with a Foundry Agent to build a business process, automating agents to react to events, run on a schedule, or both. These triggers can come from any of the 1,400+ connectors that expose them — such as ServiceNow incidents, GitHub issues, Jira tickets, and SAP IDocs — each capable of initiating a Foundry Agent. The result is that your agents do not wait for someone to interact with them. They activate the moment work arrives, reason about it, take action through their tools, and, where appropriate, hand off to long-running workflows.

Logic Apps connectors are now available as tools for Foundry Agents. Any of those same 1,400+ Azure Logic Apps connectors can now be exposed directly to a Foundry Agent as a native tool. An agent can reason about a customer issue and then update the CRM, file the ticket, send the approval, or post the message.

Invoke entire workflows, including long-running ones, as Foundry agent tools. Tools are not limited to a single API call. With Logic Apps, an agent can invoke an entire workflow as a tool: a multi-step approval that waits days for a human response, a webhook callback, a long-running orchestration spanning multiple systems, or a process that pauses and resumes on external events. The agent reasons, and the workflow executes durably for as long as the process requires.

Business process automation, durable workflows, and agentic AI are now available on the same stack.

Why this matters

Building automations with agents and deterministic logic has meant working across two separate worlds: one platform to build and host the agent, and another to connect it to the systems where work happens and to invoke it when needed. This release brings those two worlds together. Foundry and Logic Apps now work as one agentic stack, with each platform handling what it does best

Azure AI Foundry — Where agents are built and hosted	Azure Logic Apps — Where agents are invoked and orchestrated
Define agents with models, instructions, and tools	Trigger agents from any event, on any schedule
Ground responses in knowledge and enterprise data	Orchestrate multi-step, multi-agent business processes
Evaluate, version, and observe agent behavior	Expose 1,400+ connectors, workflows, MCPs, webhooks, and agents as native tools

Getting Started

If you already have a Foundry Agent and a Logic Apps environment, you're a few clicks away. Here are the steps to Create and/or Invoke Foundry Agents from Logic Apps Workflows

Add an Agent node to your workflow: In the Logic Apps designer, add the Agent node to your workflow.

Creation connection: If you don't already have a connection, you'll be prompted to create one. Make sure it's a Foundry Project connection: select Foundry Project from the Agent Model Source drop-down, then provide your project endpoint and API key.

Invoke an existing Foundry agent: Once the Agent node is added, pick an agent from the Agent drop-down. Logic Apps defaults to the latest version and shows the agent's configured model and instructions. You can invoke the agent as-is, or make changes from the designer, including adding Logic Apps tools to the Foundry Agent.

Or create a new agent: To create a new agent from the designer, provide an Agent Name and Model, then choose Create; the agent is created in Foundry. You can optionally add Instructions and Logic Apps tools before saving.

Configure Agent: When you choose to create a new agent, you add the Agent Name and Model and that allows you to Create that agent in Foundry. Optionally you can add Instructions and Logic Apps tools from the designer. The Agent is Created when you click on Create. You can invoke from Logic Apps or from Foundry portal as well.

Add tools: Logic Apps tools are how your agent takes action. A tool can include not just 1400 connectors, but also MCPs, workflows, custom code, Agents or APIs

Closing

Agents are only useful when they can act - and act autonomously, durably, and across the systems and timeframes that real business processes require. With Microsoft Foundry providing the agent platform, and Azure Logic Apps providing the triggers, workflows, connectors, webhooks, and agent-as-tool composition, AI capability turns into automated business processes.

What's new in Azure API Management at Microsoft Build 2026

beenamore — Tue, 02 Jun 2026 19:30:00 GMT

For more than a decade, Azure API Management has helped organizations secure, govern, and operate APIs at enterprise scale.

As organizations build more AI-powered applications, APIs are increasingly part of a broader architecture that includes AI models, agents, MCP tools, and agent-to-agent interactions. These new patterns increase the need for consistent governance, discovery, security, and observability across the full application ecosystem.

Azure API Management already provides AI gateway capabilities that help organizations govern and observe AI workloads. At Build 2026, we're continuing to expand those capabilities and introducing new updates that help organizations manage the growing ecosystem of APIs, models, agents, MCP tools, and AI-powered interactions.

General Availability: Azure API Center expands discovery and governance for APIs and AI assets

As organizations build more AI-powered applications, APIs are no longer the only reusable enterprise asset. Agents, MCP tools, prompts, skills, and AI services are rapidly becoming building blocks that developers need to discover, evaluate, and reuse.

To support this shift, Azure API Center now Azure API Center now supports agent registration, agent assessment, and Git-based synchronization | Microsoft Community Hub, helping organizations create a centralized catalog for APIs and AI assets.

Developers can register agents directly into API Center, making them discoverable alongside APIs and other enterprise assets. Agent definitions can be synchronized automatically from Git repositories, ensuring catalog entries remain aligned with source-controlled implementations and evolving codebases.

To help organizations establish trust and quality standards, API Center now also provides automated agent assessment using an LLM-as-a-Judge framework. Agents can be evaluated for safety, reliability, and behavioral completeness before being published to the enterprise catalog.

We're also announcing the general availability of the Azure API Center data plane MCP server. As organizations adopt MCP-based tooling and AI agents at scale, developers need a simpler way to discover and connect to the growing ecosystem of enterprise MCP servers, tools, APIs, agents, and AI assets. The Azure API Center data plane MCP server acts as a unified enterprise discovery endpoint, enabling agents and developer tools to access registered MCP servers, tools, APIs, agents, and AI assets through a single MCP connection. This allows organizations to provide centralized access to enterprise capabilities, simplify discovery across growing catalogs, and automatically make newly registered MCP servers and tools available without requiring individual client reconfiguration.

Together with agent registration, assessment, and Git synchronization, the Azure API Center data plane MCP server helps organizations create a centralized source of truth for APIs, agents, MCP tools, and AI assets improving discoverability, governance, and reuse across the enterprise

General Availability: Agent-to-Agent APIs and content safety controls

Agentic systems introduce new governance challenges. As agents begin coordinating work on behalf of applications and users, agent-to-agent communication is becoming an increasingly important architectural pattern. Historically, these interactions have often existed outside traditional API governance boundaries, creating operational blind spots and fragmented governance models.

Azure API Management now supports JSON-RPC-based Agent-to-Agent (A2A) APIs, enabling organizations to manage agent interactions alongside REST APIs, GraphQL APIs, MCP tools, and AI model APIs using the same API management platform they already rely on today.

We're also extending content safety capabilities to MCP tools and A2A interactions. Organizations can now centrally apply safety controls across model invocations, tool execution, and agent communication patterns through a unified governance layer.

Rather than introducing separate governance platforms for agents, Azure API Management enables organizations to extend familiar API governance principles to emerging agent ecosystems.

Public Preview: Unified Model API for multi-model AI applications

Most organizations are quickly discovering that AI is becoming a multi-model world. Applications increasingly combine models from Microsoft, OpenAI, Anthropic, Google, and other providers based on performance, cost, latency, regional requirements, or workload-specific needs. This creates complexity for developers and platform teams alike. Different providers expose different APIs. SDKs vary. Governance becomes fragmented. Switching providers often requires application changes.

To simplify multi-model architectures, we're introducing the Unified Model API in public preview.

The Unified Model API allows organizations to standardize on a single client-facing API format while Azure API Management transparently handles provider-specific transformations behind the scenes. Developers can continue using familiar APIs and SDKs while platform teams gain the flexibility to route traffic across multiple providers, implement failover strategies, and evolve model choices over time. By abstracting provider-specific differences behind a unified API layer, organizations can build more portable, resilient, and governable AI applications.

General Availability: Expanded AI Gateway support for Anthropic and Vertex AI

Azure API Management AI gateway capabilities already helps organizations govern and observe AI traffic across model providers. As multi-model architectures become increasingly common, organizations need consistent governance regardless of where those models are hosted.

API Management now extends AI Gateway capabilities to Anthropic and Google Vertex AI models. Organizations can apply runtime governance, security controls, content safety policies, semantic caching, token controls, logging, tracing, and observability across a broader range of AI providers.

This enables platform teams to apply consistent governance practices across multi-model environments without introducing separate management tools or operational processes for each provider.

General Availability: Expanded token observability for AI workloads

Understanding AI usage is becoming increasingly important as model providers introduce new token types beyond traditional prompt and completion tokens.

Azure API Management now supports token metrics for all token types, including cached, reasoning, and thinking tokens, with metrics available through Application Insights.

Organizations can collect token usage data across multiple providers and API formats, build more accurate cost dashboards, improve budget monitoring, and gain deeper visibility into evolving model behaviors. As AI workloads continue to grow, expanded token observability helps organizations better manage costs, optimize usage, and strengthen governance across AI applications.

General Availability: Enterprise platform enhancements

Alongside our AI-focused investments, we're continuing to expand the core platform capabilities organizations rely on to operate API programs at scale.

Azure API Management Premium v2 now supports multiple custom domains, allowing organizations to expose APIs, developer portals, and management endpoints under multiple branded experiences while maintaining centralized governance.

Azure API Management Premium v2 and Standard v2 now support wildcard custom hostnames, significantly reducing certificate and hostname management overhead for growing API estates.

We're also expanding workspace support to the built-in gateway. Organizations can now adopt team-based governance and delegated API management models across additional deployment options while benefiting from built-in gateway capabilities such as multi-region deployments, custom hostnames, and Private Link connectivity.

Together, these enhancements make it easier for organizations to scale up API programs while maintaining operational simplicity.

Looking ahead

APIs remain the foundation of modern applications.

But increasingly, they are no longer the only assets developers interact with. Models, agents, MCP tools, and agent-to-agent interactions are becoming important components of enterprise application architectures.

The governance challenge is no longer limited to APIs alone.

With these Build announcements, Azure API Management and Azure API Center continue to expand the governance foundation organizations rely onhelping teams discover, secure, govern, and observe APIs, models, agents, MCP tools, and AI interactions through a unified platform experience.

As organizations build the next generation of AI-powered applications, we're committed to providing the governance, security, visibility, and operational controls required to run those systems with confidence at enterprise scale.

Azure Connector Namespaces: managed integration for any Azure compute

WSilveira — Tue, 02 Jun 2026 20:33:37 GMT

The integration tax nobody budgets for

It is always a simple task on paper: connect apps to the systems the business actually runs on — SharePoint, Salesforce, SAP, Outlook — and get back to building features. What gets in the way is rarely the business logic. It's the plumbing. You write a custom API client for each service. You wire up OAuth flows and then babysit token refresh. You add retry policies, handle throttling, page through results, and stand up webhook subscriptions you now have to keep alive. None of that is the feature. All of it is on you.

Historically, if you wanted that work done for you, the answer was a workflow engine. That's great when you want a workflow — but a lot of apps just want to call an action or react to an event from code they already have, running on the compute they already use. That's the gap Azure Connector Namespace fills.

What is Azure Connector Namespace?

Azure Connector Namespace is a fully managed integration service that hosts a catalog of prebuilt, reusable connectors and MCP servers that your apps consume through a consistent programming model. Instead of writing and operating a client for each system, you create a connection once and call typed operations from your code. The namespace handles authentication, credential rotation, polling, webhook delivery, retries, throttling, and error handling on your behalf.

Worth saying clearly, because people ask: a connector namespace is independent of Azure Logic Apps. It doesn't require, use, or change anything in Logic Apps, and the Logic Apps connectors gallery keeps working separately for workflows. Connector Namespace is the integration path for compute that doesn't run on a workflow engine — your Functions, Container Apps, App Service, and self-hosted services.

Each connector exposes three kinds of surface through one shared connection model:

Triggers — event subscriptions your app registers (a new email arrives, a record updates, a file lands in a folder).
Actions — operations your app calls (send a message, read a row, upload a file).
AI agent tools — the same operations, exposed to agents and Copilot through MCP servers.

You call all of it from strongly typed SDKs for C# (Azure.Connectors.Sdk), Node.js (@azure/connectors), and Python (azure-connectors) — or over plain HTTP if a typed SDK isn't a fit.

The building blocks

Five concepts and you have the whole model:

Concept	What it is
Connector namespace	The Azure resource that hosts the connector runtime — loads and runs operations, maintains connection state and credentials, polls source systems, dispatches webhook events, and applies retry and diagnostic policies. Create it from the Azure portal, ARM/Bicep, or the CLI.
Connector	A prebuilt component for one service (SharePoint, Salesforce, SAP, Outlook). It abstracts the underlying API, auth protocol, pagination, and retry behavior so your code stays on business logic.
Connection	An authenticated, configured binding to an account or tenant. Connections are reusable — multiple apps and connectors can share one. Auth types: OAuth, API key, and Basic.
MCP server	A first-class resource that exposes tools to AI agents over the Model Context Protocol. Comes in managed and hosted flavors (more below).
Connector SDKs	Strongly typed clients for C#, Node.js, and Python that share the same catalog, connection model, telemetry, and retry semantics. Or call connectors over HTTP.

What you can actually do with it

The point of all this is the scenarios it unlocks. A few that show the range:

Scenario	What it looks like
Process documents and content	An Azure Function uses SharePoint connector operations to detect new or updated files, processes them, and writes results back to SharePoint.
Monitor events from external services	An Azure Container App uses a Salesforce trigger to receive events about new leads as they're created.
Automate productivity	A Node.js app uses Outlook operations to read and send email — reusing a connection another app already owns.
Ground AI and agentic workloads	A Python service calls connector actions to enrich model output with data from business systems.
Reuse existing app code	ASP.NET, Node.js, and Python services use managed integrations with no workflow engine in the call path.
Publish connectors to agents	Turn any connector into an MCP server in one step so Copilot and other agents can call it as a tool.

Connections: authenticate once, reuse everywhere

Connections are where the Logic Apps connector ecosystem pays off. You get the same broad catalog of first-party Azure services and popular SaaS apps — built on years of connector investment — without bringing a workflow engine along for the ride. You create a connection to a service, authenticate it once, and then any number of apps and connectors reuse it.

Creating one is deliberately simple, which is the point:

In the Connector Namespaces portal (connectors.azure.com), open your namespace and select Connections > Create connection.
Find and select the connector — say, Office 365 Outlook.
Give the connection a clear, specific name so it's easy to pick later.
Sign in to authorize, and complete any extra steps the service requires.
Confirm the connection shows as healthy on the Overview page — it's now ready for your apps to use.

Supported authentication types today are OAuth, API key, and Basic. And because the namespace stores and rotates the credentials, your app never touches a raw secret.

Triggers: deliver events to the compute you already run

A trigger is an event subscription your app registers on a connector — new email, updated record, new file. When the source system raises that event, the namespace delivers the payload to your compute. And it does the hard part for you: it manages polling schedules and webhook registration based on what the underlying service supports, so you don't stand up or maintain subscription infrastructure.

Your app can receive those events running on:

Azure Container Apps Sandboxes
Azure Functions
Direct HTTP — App Services or self-hosted ASP.NET, Node.js, or Python on AKS or VMs, through the same connector namespace.

Two details that matter in practice: a trigger is defined independently of any specific app, and multiple apps can subscribe to the same trigger event over the same connection. Actions, for contrast, run synchronously when your app calls them; trigger delivery uses webhooks or pull-based subscriptions depending on the connector and source service.

You can learn more about how to use the Connectors SDK to inject connectors on Azure Functions here.

MCP servers: turn connectors into agent tools

This is the part I'm most excited about. An MCP server in your namespace exposes tools that AI agents — Copilot, custom agents, any MCP-aware client — can discover and call, using the same connection model as everything else. That's how you put your line-of-business systems directly in front of an agent without writing tool wrappers or standing up hosting. There are two ways to get one.

Managed MCP servers

Take any connector in your namespace and publish it as an MCP server in a single step. The namespace builds and configures the server — tool definitions, lifecycle, runtime — and the only thing you do is authenticate the underlying connection. If you can create a connection, you can give an agent a tool.

Hosted MCP servers

Sometimes you want a ready-made server rather than one projected from a connector. Hosted MCP servers are pre-built images from a curated catalog that the namespace runs in dedicated compute it provisions for you. You own the configuration; the platform handles hosting, scaling, networking, lifecycle, dependencies, health monitoring, and credentials. When you deploy one, the namespace pulls the image, provisions the runtime with your config, and exposes a secure MCP endpoint agents can connect to.

The curated catalog during preview includes:

Playwright — browser automation tools for navigation, screenshots, and page interaction.
Azure SQL — SQL operations exposed as MCP tools through Data API builder, with entity abstraction, RBAC, and caching so agents work through a controlled, secure contract.

It's a deliberately curated set today, and it expands over time based on demand. You can learn more about Hosted MCP Servers here.

How agents authenticate

Hosted MCP servers have two auth boundaries:

Inbound (client to server) — OAuth with Microsoft Entra ID. Connections from GitHub Copilot in VS Code work out of the box; other MCP clients need a little extra config.
Outbound (server to downstream system) — either a managed identity assigned to the namespace, or on-behalf-of (OBO) using the calling user's identity for delegated access.

How it fits together

End to end, the flow for connectors is short:

Create a connector namespace resource in your subscription.
Create one or more connections to the services you want — say, an OAuth connection to Microsoft 365.
Your app — in Functions, Container Apps, App Service, or self-hosted compute — references the namespace and connection through a Connector SDK, then subscribes to triggers or calls actions.
The namespace handles authentication, request signing, polling, webhook subscription, and retries. Your app gets back typed responses and event payloads.

For MCP servers, it's the same shape: create the namespace, add a managed or hosted server from the catalog, authenticate the underlying connection, and agents can find the server, read its tool catalog, and invoke tools.

Where you can run it

Azure compute — App Service, Container Apps, and Functions can all consume connector operations.
Self-hosted — any self-hosted service works too: ASP.NET, Node.js, or Python on AKS or Azure VMs.
Agents, directly — Copilot extensions and MCP-aware clients call tools on MCP servers in your namespace without going through a separate compute layer; the namespace provides the compute that runs the servers.

Security and governance, by default

Credentials stay with the namespace — it stores, manages, and rotates them; your app never handles raw secrets.
Network isolation — restrict access with virtual network integration and private endpoints.
RBAC — control who can create connections, register triggers, and invoke actions.
Observability — diagnostic logs and correlation IDs flow to Azure Monitor for end-to-end tracing across the namespace and your compute.

Before you build: preview realities

I'd rather you go in clear-eyed. While Connector Namespace is in preview, keep these in mind:

Consideration	What to expect
No SLA	Not recommended for production workloads during preview.
Region availability	Limited regions today; the list expands over time.
Connector coverage	High-usage and standard connectors first; enterprise connectors like SAP, IBM MQ, and Oracle Database follow in later waves.
Identity	API key and OAuth connections now; managed identity for connections comes later (and arrives earlier for select MCP servers).
Versioning	SDK and namespace runtime versions are paired during preview — expect breaking changes between milestones.
Pricing	The pricing model isn't finalized; the metering shape may change before GA.

Try it, and tell us your feedback

If you've ever shipped an integration and then spent the next quarter maintaining its plumbing, this is for you. The preview is open: create a namespace from the Azure portal, wire up a connection at connectors.azure.com, and call your first action or publish your first MCP server. It is easy to start here:

Learn more:

What's new in Azure Logic Apps at Microsoft Build 2026

beenamore — Tue, 02 Jun 2026 19:30:00 GMT

Automation is entering a new era

Automation has traditionally been powerful, but not always accessible.

Building production-grade automations often requires specialized expertise in workflows, integrations, APIs, infrastructure, identity, security, networking, and operations. Organizations could build sophisticated solutions, but doing so typically requires dedicated development or integration teams

AI is changing that equation.

Across every organization, more people want to automate work. Developers want to build AI-powered applications faster. Startup teams want to move from idea to production without assembling complex infrastructure. Operations, security, and business teams want to leverage AI to automate repetitive processes and accelerate decision making.

Expectations have changed as well. Builders increasingly expect natural language experiences, AI assistance, integrated knowledge, and faster paths from idea to execution.

At the same time, organizations still need the governance, security, reliability, compliance, and operational controls required to run automation in production.

This creates a new opportunity: making enterprise-grade automation accessible to far more builders without sacrificing the foundations required to operate at scale.

At Build 2026, we're introducing Azure Logic Apps Automation along with several new Azure Logic Apps capabilities that help organizations build, connect, and operationalize AI-powered automation on Azure.

Public Preview: Azure Logic Apps Automation

Azure Logic Apps Automation is a new Logic Apps SKU designed to make enterprise-grade automation dramatically easier to build. Built on the same Azure platform organizations trust today, Logic Apps Automation provides a managed environment where workflows, AI agents, enterprise connectivity, knowledge services, and model access are available out of the box. A built-in AI assistant helps users move from intent to implementation using natural language. Developers can generate workflows, configure actions, create expressions, and build automations faster while maintaining full control over the final implementation. Logic Apps Automation also brings AI agents directly into the automation experience. Developers can build and use Microsoft Foundry agents alongside traditional workflow actions, enabling business processes that combine deterministic execution with AI-driven reasoning.

Whether you're a startup building AI-native applications, an enterprise modernizing internal processes, or a developer looking to accelerate automation projects, Logic Apps Automation provides a simpler path from idea to production.

General Availability: Azure Logic Apps MCP Server

As AI agents become increasingly important participants in enterprise applications, organizations need a straightforward way to connect those agents to existing business processes.

The Azure Logic Apps MCP Server is now generally available and enables developers to expose existing Logic Apps workflows as MCP-compatible tools that agents can discover and invoke directly.

This allows organizations to reuse years of existing automation investments without building custom APIs or integration layers. Workflows that already connect enterprise systems, business applications, and operational processes can now become AI-callable capabilities in minutes.

Public Preview: Invoke Microsoft Foundry Agents directly from Logic Apps

Organizations increasingly build agents in Microsoft Foundry. With new Foundry integration capabilities, developers can now invoke Foundry agents directly from Logic Apps workflows. This enables business processes that combine enterprise systems, APIs, human approvals, schedules, events, and AI-driven reasoning within a single automation experience. Workflows can trigger agents, agents can provide analysis or recommendations, and Logic Apps coordinates the broader business process around those outcomes.

Public Preview: Knowledge as a Service

One of the biggest challenges organizations face when building AI-powered applications is making enterprise knowledge accessible. Retrieval-augmented generation often requires ingestion pipelines, chunking strategies, embedding models, vector databases, and retrieval infrastructure before developers can begin building the experiences they actually care about.

Knowledge as a Service simplifies this process. Developers can upload documents directly into Logic Apps workflows, automatically ingest and process content, generate embeddings, and use retrieval as a built-in workflow capability. Instead of building and operating knowledge infrastructure, teams can focus on creating grounded AI experiences and intelligent automations that leverage organizational knowledge.

Public Preview: Codeful Workflows with the Logic Apps Standard SDK

Different developers prefer different ways of building software. Some teams prefer visual workflow design. Others want the flexibility and familiarity of code-first development.

Codeful Workflows introduces a new code-first development experience for Azure Logic Apps Standard. Built on the Logic Apps Standard SDK, Codeful Workflows enable developers to create workflows directly in code using familiar .NET development patterns while continuing to benefit from Logic Apps connectors, orchestration capabilities, and operational infrastructure. Developers can build, test, debug, and run workflows locally while leveraging existing development tools, source control practices, and AI-assisted coding experiences. This gives teams more flexibility in how they build automation while preserving the benefits of the Logic Apps platform.

Public Preview: Migration Agent for Azure Logic Apps

Modernization remains a top priority for many organizations as they evaluate legacy integration platforms and prepare for the next generation of cloud-native architectures.

The new Migration Agent for Azure Logic Apps helps simplify that journey.

Designed to assist organizations migrating from BizTalk Server and other third-party integration solutions, the Migration Agent provides intelligent assessments, migration guidance, compatibility analysis, and automated recommendations. By reducing the manual effort traditionally associated with migration projects, organizations can accelerate modernization initiatives while lowering risk and improving confidence throughout the migration process.

Looking ahead

The future of automation is not simply about adding AI to existing workflows.

It's about making powerful automation accessible to more builders while preserving the governance, reliability, security, and operational controls organizations require.

Azure Logic Apps has long provided the foundation for enterprise integration and business process automation. With Logic Apps Automation, Foundry agent integration, MCP support, Knowledge as a Service, Codeful Workflows, and AI-powered migration capabilities, we're continuing to expand what's possible while making it easier for organizations to move from idea to production.

We're excited to see what developers, startups, enterprises, and builders of every kind create next.

Hosted MCP Servers in Connector Namespace (Preview)

lily-ma — Thu, 04 Jun 2026 21:19:18 GMT

Imagine you've built an agent and you want to give it access to tools via MCP servers. Local servers won't work because your agent can't connect to them in production. Wouldn't it be great if you could quickly stand up secure, enterprise-ready remote MCP servers that your agent can use?

This is what Connector Namespace enables. Among other capabilities, the namespace provides a feature called hosted MCP servers that lets you deploy remote MCP servers in minutes. Pick a server from the catalog, deploy it and your agents can discover and call its tools immediately, with infrastructure, deployment, scaling, observability, authentication, and more handled by the platform.

Why hosted MCP?

Self-hosting MCP servers comes with real operational cost: infrastructure, authentication, monitoring, scaling, availability, and debugging are all on you. For servers that expose standard capabilities like database access or browser automation, that's undifferentiated work that slows you down.

Hosted MCP servers shift that burden to the platform, offering a fully managed experience so you can just pick a server and let the platform handle everything else:

	Hosted MCP server	Self-hosted MCP server
Setup	Deploy from catalog in minutes	Build/find server, deploy to your own infra, wire up networking
Scaling	Platform-managed, scales automatically	You configure and manage scaling (VMs, containers, load balancers)
Auth	Inbound and outbound auth handled by the platform	You configure OAuth, managed identity, or OBO end-to-end
Observability	One-click App Insights integration	You set up logging, metrics, and alerting yourself
Cold starts	Platform manages server lifecycle	You manage warm-up, health checks, and process restarts
Availability	Platform-managed uptime, health monitoring, and automatic recovery	You own high availability, e.g. failover and redundancy

How it works

When you deploy a hosted MCP server, the namespace:

Pulls the pre-built server image from the catalog.
Provisions the runtime environment with your configuration.
Exposes a secure MCP endpoint that agents and MCP clients can connect to.
Handles scaling, health monitoring, and authentication.

Public preview feature highlight

Supported servers

During public preview, a curated set of hosted MCP servers is available. The catalog expands over time based on demand.

Server	What it does
Playwright	Browser automation tools for web navigation, screenshots, and interaction
Azure SQL	Exposes SQL operations as MCP tools through Data API builder, enabling AI agents to interact with SQL databases through a controlled, secure contract with entity abstraction, RBAC, and caching.

If there's a server you'd like to see in the catalog, file an issue at aka.ms/hosted-mcp-github. Support for publishing custom-built MCP servers to the catalog is planned for the future.

Authentication

Hosted MCP servers involve two authentication boundaries:

Inbound (client → server): OAuth-based authentication with Microsoft Entra ID. Connections from GitHub Copilot in VS Code work out of the box.
Outbound (server → downstream service) The server authenticates to the downstream service using either managed identity or on-behalf-of (OBO) flow. You choose the approach during deployment, and the platform handles the rest, including credential management and token exchange.

Observability

Hosted MCP servers integrate with Azure Application Insights], so you can monitor server health without setting up your own logging infrastructure. After deployment, you can enable monitoring by providing your Application Insights connection string. Once configured, logs and metrics from the server flow directly into your Application Insights resource, where you can search, filter, and analyze them.

Get started

Quickstart: Create a hosted MCP server in Connector Namespace
Hosted MCP overview: Hosted MCP servers in Connector Namespace
Connector Namespace overview: What is Connector Namespace?

Try it out and let us know what you think! File feedback and feature requests at aka.ms/hosted-mcp-github.

What's next

Hosted MCP servers are in public preview and the team is actively working to improve the experience. We're looking for your feedback to help shape what comes next. Some areas we're prioritizing:

Expanding the server catalog: adding more servers based on demand and community requests
Region availability: expanding regional coverage beyond the current preview regions
VNet support: deploying Hosted MCP servers inside virtual networks with private endpoints
Custom server images: support for bringing your own MCP server images to the catalog
Tool-level access control: fine-grained permissions and throttling at the individual tool level

MCP Test Console and Git Repository synch in Azure API Center

Sreekanth_Thirthala — Tue, 02 Jun 2026 19:14:03 GMT

Why This Matters

As organizations race to build AI-powered applications, the Model Context Protocol (MCP) has emerged as the standard way to connect AI agents with external tools and data sources. Managing these MCP servers at enterprise scale, however, has been a growing challenge — until now.

AI agents are only as useful as the tools they can access. MCP servers expose those tools — from databases and internal APIs to third-party services — in a standardized way that any AI agent or model can consume. As your MCP ecosystem grows, so does the challenge of keeping track of what's available, what's working, and what your teams are actually using.

Azure API Center already serves as a centralized registry for APIs across your organization. Now it extends that same governance model to MCP servers, complete with developer-friendly discovery, live testing, and automated synchronization from your source repositories.

New Feature: MCP Test Console in the API Center Portal

Developers can now test MCP server tools interactively without leaving the Azure portal.

Once an MCP server is registered in your API Center inventory, the API Center portal — your organization's customizable developer portal — surfaces a dedicated test console on the server's Documentation tab. Developers simply select a tool, click Run tool, and immediately see the response.

This means your teams can:

Validate tools before connecting them to agents — no more building a test harness from scratch.
Explore tool schemas interactively — the portal surfaces endpoint details and input/output schemas alongside the live console.
Onboard faster — developers browsing your internal MCP registry can go from discovery to verified integration in minutes.

The MCP server tiles in the portal provide a clear, browsable view of all registered servers. Each tile surfaces the server's endpoint URL, available tools, and installation instructions for Visual Studio Code — giving developers everything they need to get started in one place.

Getting started: Set up your API Center portal, then navigate to any registered MCP server. On the Documentation tab, select a tool and click Run tool to open the test console.

New Feature: Synch MCP Servers from a Git Repository

Managing API assets shouldn't require manual registration every time something changes. With Git repository integration, Azure API Center can automatically sync assets — including MCP server definitions — directly from your source repository.

How It Works

When you connect a Git repository to your API Center:

An environment is created in your API Center representing the repository as an asset source.
API Center regularly synchronizes MCP servers from the repository into your inventory — no manual intervention required.
Assets appear in your inventory on the Inventory > Assets page with a visual link indicator, making it easy to identify which assets are source-controlled.

This is especially valuable for teams that maintain MCP server definitions, skill files, or OpenAPI specs in version control. As your repository evolves, your API Center inventory stays current automatically.

Setting It Up

Step 1: Secure your access credentials (for private repos)

If your repository is private, store a personal access token (PAT) as a secret in Azure Key Vault. Your API Center instance uses a managed identity to retrieve this secret securely — you can configure the managed identity manually or let API Center handle it automatically during the integration setup.

Step 2: Connect the repository

In the Azure portal, go to your API Center and navigate to Platforms > Integrations > + New integration > From Git repository. You'll configure:

Repository URL — including an optional branch and subfolder path (e.g., https://github.com/<org>/<repo>/tree/main/skills).
Git provider — such as GitHub.
Asset type configuration — API Center defaults to a skill asset type with the file pattern **/skill.md, but you can add additional asset types to match your repository structure.
PAT reference — select the Key Vault secret containing your PAT, if applicable.
Environment details — give the repository environment a friendly name, resource ID, type (e.g., Production), and lifecycle stage for synced assets.

Step 3: Let the sync run

Once created, the integration runs automatically. Your assets will appear in the Inventory > Assets view, linked to their source in the repository.

Access Control for Private Repositories

The integration uses Azure's managed identity framework to authenticate to Key Vault. Assign your API Center's managed identity the Key Vault Secrets User role on your Key Vault to grant the necessary read access. If you prefer, API Center can configure this automatically — just enable the Automatically configure managed identity and assign permissions option during integration setup.

Bringing It Together: A Complete MCP Governance Story

Together, these two features complete an end-to-end workflow for enterprise MCP governance:

Register → Connect your Git repository and let API Center automatically synch your MCP servers and skills as they evolve.

Discover → Developers and AI engineers browse the API Center portal to find the right MCP server for their agent, with full schema visibility and endpoint details.

Test → The built-in test console lets developers validate tools interactively before committing to an integration.

Govern → Use API Center's access management capabilities to control who can view and consume specific MCP servers across your organization.

And if you're building MCP servers on Azure services, the registry integrates directly with Azure API Management, Azure Logic Apps, and Azure Functions — so your MCP ecosystem and your API ecosystem share a single source of truth.

Get Started

Register and discover MCP servers in Azure API Center
Synchronize API assets from a Git repository
Set up the API Center portal
Explore MCP Center — Azure API Center's public MCP registry