Power Automate connectors for Dynamics 365

Power Automate connectors are the bridges between flows and other systems. For Dynamics 365 customers, several connectors matter — and the difference between standard and premium connectors is important for licensing and capability.

Microsoft Dataverse connector

The right connector for any CRM-side D365 app (Sales, Customer Service, Field Service, Project Operations, Customer Insights, Power Apps with Dataverse). Triggers on row created/updated/deleted/added; actions for full CRUD, executing actions, file uploads, and relating records. Supports filtering and column selection. Premium connector — flows using it require a Power Automate per-user or per-flow licence beyond what's included with most Dynamics 365 SKUs.

Common Data Service (current environment) connector

The older name; functionally equivalent and being phased out in favour of "Microsoft Dataverse". Still appears in older flow templates.

Dynamics 365 connector (legacy)

An older connector for CRM-side apps, predating Dataverse-native. Microsoft recommends migrating to the Dataverse connector.

Dynamics 365 Business Central connector

First-party. Triggers and actions for Customer, Vendor, Item, Sales Order, Purchase Order, Sales Invoice, Sales Quote, Journal Lines, Locations, and many more. Standard CRUD and bound actions for posting, releasing, and cancelling documents. Premium.

Dynamics 365 Finance and Operations (legacy) connector

Targets F&O data entities. Premium.

Dynamics 365 for Fin & Ops (Recurring Integrations)

A separate connector that targets the recurring integration API for batched data project imports/exports.

Custom connectors

When the first-party connector doesn't expose what you need, build a custom connector from an OpenAPI/Swagger definition. Custom connectors are premium and use the same authentication and policy framework as built-in ones.

Licensing

This is where teams get caught out. A flow that uses only standard connectors (SharePoint, Outlook, Teams, Office 365) can run on the free Power Automate licence bundled with M365. A flow that uses a premium connector — Dataverse, Business Central, F&O, SQL Server, HTTP, custom connector — requires a premium Power Automate licence on the flow owner. Per-user (one user, unlimited flows) or per-flow (one flow, unlimited users) plans are available. Most Dynamics 365 SKUs include limited premium Power Automate rights, often labelled "Power Automate for Dynamics 365" — these allow flows that are directly related to the licensed Dynamics 365 app, but not arbitrary Power Automate use.

Throttling

Each connector has request limits per user per 24h, plus shorter spike limits. Bursty flows can hit the limits and produce HTTP 429s. Throttle limits are documented per connector; the most common D365 connector limits are generous but real — see throttling and 429 errors for how to read the response headers and design around them.

Connector cheat sheet

Connector	Standard or premium	Typical use
Microsoft Dataverse	Premium	Any CRM-side app: Sales, Customer Service, Field Service, Project Operations, custom Power Apps
Dynamics 365 Business Central	Premium	Sales/purchase documents, items, customers, journal lines in BC
Dynamics 365 Finance and Operations (legacy)	Premium	F&O data entities via the older connector surface
SharePoint, Outlook, Teams, Office 365 Users	Standard	Notifications, document handling, approvals bundled into a D365-adjacent flow
HTTP / custom connector	Premium	Anything with no first-party connector — a partner API, a legacy on-prem system via gateway
Approvals	Standard	Human-in-the-loop steps inside an otherwise premium flow

Mixing standard and premium connectors in the same flow makes the whole flow premium — there is no "mostly free" middle ground. A flow that sends a Teams notification and updates a Dataverse row needs a premium licence on its owner because of the Dataverse step, even though Teams alone is standard.

Connection references and ownership

In a solution-aware (managed) environment, flows use connection references rather than embedding a personal connection directly. This decouples "who built the flow" from "whose credentials it runs under" and is what makes a flow survive its original author leaving the team — a connection reference can be repointed to a service account or another maker's connection without editing the flow itself. Skipping connection references (building directly against a personal connection) is the most common reason a flow silently breaks when its author's account is disabled.

Choosing a connector when more than one option exists

For CRM-side data, the modern default is always the Microsoft Dataverse connector — the legacy Dynamics 365 and Common Data Service (current environment) connectors exist only for backward compatibility with flows built years ago, and Microsoft's own guidance is to migrate off them. For Business Central, the first-party connector covers the vast majority of document and master-data scenarios; reach for the BC API directly through an HTTP or custom connector only when a specific endpoint the first-party connector doesn't expose (a custom API page, for instance) is genuinely required.

Connector cheat sheet

Connector	Standard or premium	Typical use
Microsoft Dataverse	Premium	Any CRM-side app: Sales, Customer Service, Field Service, Project Operations, custom Power Apps
Dynamics 365 Business Central	Premium	Sales/purchase documents, items, customers, journal lines in BC
Dynamics 365 Finance and Operations (legacy)	Premium	F&O data entities via the older connector surface
SharePoint, Outlook, Teams, Office 365 Users	Standard	Notifications, document handling, approvals bundled into a D365-adjacent flow
HTTP / custom connector	Premium	Anything with no first-party connector — a partner API, a legacy on-prem system via gateway
Approvals	Standard	Human-in-the-loop steps inside an otherwise premium flow

Mixing standard and premium connectors in the same flow makes the whole flow premium — there is no "mostly free" middle ground. A flow that sends a Teams notification and updates a Dataverse row needs a premium licence on its owner because of the Dataverse step, even though Teams alone is standard.

Connection references and ownership

In a solution-aware (managed) environment, flows use connection references rather than embedding a personal connection directly. This decouples "who built the flow" from "whose credentials it runs under" and is what makes a flow survive its original author leaving the team — a connection reference can be repointed to a service account or another maker's connection without editing the flow itself. Skipping connection references (building directly against a personal connection) is the most common reason a flow silently breaks when its author's account is disabled.

Choosing a connector when more than one option exists

For CRM-side data, the modern default is always the Microsoft Dataverse connector — the legacy Dynamics 365 and Common Data Service (current environment) connectors exist only for backward compatibility with flows built years ago, and Microsoft's own guidance is to migrate off them. For Business Central, the first-party connector covers the vast majority of document and master-data scenarios; reach for the BC API directly through an HTTP or custom connector only when a specific endpoint the first-party connector doesn't expose (a custom API page, for instance) is genuinely required.

The pattern

For any non-trivial flow involving Dynamics 365, plan: which premium connectors does it call, who owns it (ideally a service account behind a connection reference, not a named person), and what licence does the owner have. Decide this before building, not after a flow silently stops working when someone's trial licence lapses.