One of the announcements from Build 2026 that caught my attention is Managed connectors (Preview).
What is it?
In simple terms, you can now write real code in Azure Functions and use more than 1,400 existing connectors such as Salesforce, Teams, Outlook, SAP, ServiceNow, and SharePoint as if they were part of your function. This works for any custom SaaS endpoint as well.
No custom API wrappers. No token management. No authentication plumbing.
For anyone new to Azure Functions, think of it as code that runs when something happens. An HTTP request comes in, a queue message arrives, a timer fires, and your code executes.
Before now, if your function needed to talk to Salesforce, Outlook, Teams, Dataverse or another business system, you had to handle the integration yourself. That meant authentication flows, SDKs, API calls, retries, and error handling.
Logic Apps already solved that problem with its connector ecosystem, but many developers prefer a code first approach and don’t always want to switch to a drag and drop designer.
This update brings both worlds together.
What happens now?
Azure Functions is still what it has always been: code that runs when something happens.
HTTP request comes in → your function runs.
Timer fires every 5 minutes → your function runs.
Queue message arrives → your function runs.
Instead of hand-rolling integrations for connectors not available via binding, you can call managed connectors for:
Salesforce
Microsoft Teams
Outlook / Exchange Online
SharePoint
SAP
ServiceNow
Dynamics 365
And ~1,400 others
And the auth, token refresh, connection management, and API wiring are handled for you.
When you use the Connector namespaces automatically, you get the following:
Connector triggers. First-class Functions triggers: Office 365 new-email, Teams message-posted, SharePoint item-created/updated, Dataverse row-changed, Salesforce record-updated and more
Typed connector SDKs. Strongly-typed client libraries for invoking connector actions from inside your function — OutlookClient, TeamsClient, Office365UsersClient, DataverseClient, SalesforceClient, and growing.
Auth via managed identity and built-in authentication. Configure the function app with built-in authentication to allow only the Connector Namespace to trigger the function.
Observability. Every connector trigger run is recorded with information about the run.
Okay, but what’s the cost?” Fair question.
The integration itself does not introduce a separate new Azure Functions charge.
- You pay for Azure Functions execution based on your hosting plan.
- Connector calls are billed using the same connector pricing model that Logic Apps uses today.
Where this fits best
I see three strong scenarios for this right now.
1. Code-first integrations with SaaS and enterprise systems
If your team builds APIs, background workers, webhook processors, or event-driven integrations, this is a cleaner model than mixing raw SDKs, custom OAuth handlers, and scattered secrets.
You keep the flexibility of Functions, but remove a lot of integration boilerplate.
2. Modernizing old integration stacks
A lot of customers still have:
SSIS packages
BizTalk workloads
Windows services polling mailboxes
Custom .NET integration apps running on VMs
Scheduled scripts glued together with APIs
This is a strong modernization path:
Serverless runtime,
Managed connectors,
Event-driven execution,
Identity-based access,
IaC + CI/CD friendly.
3. Customers already using Logic Apps and Functions together
This is probably the most practical adoption path.
Use Logic Apps for:
Long-running workflows
Approvals
Human-in-the-loop processes
Complex orchestration and branching
Use Azure Functions for:
Code-heavy processing
Webhooks and APIs
Custom business logic
High-throughput event handling
Reusable integration services
Now both can use the same connector library, which simplifies architecture and governance.
The managed connectors in Azure Functions really shine when you need business logic, AI, data transformation, or custom code between the trigger and the action.
I demonstrated this in the video:
📧 Email arrives → 🧠 Function determines importance → 📋 Adds business context → 💬 Posts to Teams → 🚩 Flags email for follow up
A Connector Namespace trigger watches the M365 Outlook Inbox and POSTs every new email to an Azure Functions webhook URL. The function classifies importance with a small in-process .NET heuristic, and for the messages that pass the bar it enriches them with sender history (Office 365 Outlook), an IN-ORG / EXTERNAL badge + manager (Office 365 Users), posts a triage card to a configured Teams channel, and flags the source email in Outlook for a server-side follow-up reminder.
Important: Read Official Announcement from Microsoft: Announcing managed connectors for Azure Functions (Preview)
See samples to create yours in your environment: Azure Functions connectors samples
That’s all for today, see you in the next one.
