Power Automate for Dynamics 365: Triggers, Actions, Licensing

What Power Automate does with Dynamics 365

Power Automate is Microsoft's low-code/no-code platform for automating workflows across cloud and desktop applications. For a Dynamics 365 customer, it extends the native automation already inside each D365 app - classic workflows, business process flows, and Power Automate-templated flows - with event-driven automations that cross application boundaries, human-in-the-loop approvals, AI Builder, process mining, and robotic process automation (RPA) for legacy and desktop work.

In practice, that means a row event in Dynamics 365 - an opportunity moved to Won, a case escalated, a work order completed, a customer payment posted - can automatically send a Teams adaptive card, write a row to another Dataverse table, kick off a multi-step approval chain, post a message to a partner portal, or trigger an unattended bot that reconciles a legacy desktop system. Power Automate is the connective tissue that lets the D365 suite behave like one platform instead of a set of separate apps.

It is not, however, a replacement for native D365 automation in every case. Power Automate runs asynchronously, is subject to throttling and request limits, and cannot deliver sub-second real-time sync. The honest framing for SMEs is that Power Automate is the right tool for event-driven orchestration and cross-system workflows, while native D365 business rules, classic workflows, plugins, and AL extensions remain the right tools for synchronous, high-volume, or deeply transactional logic.

• →Low-code orchestration across D365 apps and the wider Microsoft/cloud stack
• →Extends native D365 automation with cross-app, event-driven, and approval workflows
• →Adds AI Builder, process mining, and desktop-flow RPA for legacy and UI-based tasks
• →Asynchronous by design - plan around throttling, not real-time sync

The two Dynamics 365 connectors (and the deprecated one)

The single most common point of confusion for SMEs is which connector to use. Dynamics 365 is not one database; it is two platform families, and Power Automate reflects that with two premium connectors.

For the customer-engagement and CRM-side apps - Dynamics 365 Sales, Customer Service, Marketing, and Field Service, which all run on Microsoft Dataverse - the connector you want is the Microsoft Dataverse connector (premium). It was formerly called the Common Data Service connector, and it is the primary integration surface for anything that touches accounts, contacts, leads, cases, opportunities, or work orders in those apps.

For the ERP-side apps - Dynamics 365 Finance, Supply Chain Management, and the related finance and operations apps - the connector is the Fin & Ops Apps (Dynamics 365) connector (premium). It accesses data entities rather than raw tables and supports business events such as 'When a Business Event occurs' for posted payments, confirmed sales orders, and similar events.

The old Dynamics 365 connector (dynamicscrmonline) is deprecated. If you have legacy flows built on it, plan a migration to the Dataverse connector for customer-engagement apps - Microsoft's guidance is explicit on this, and the deprecated connector will not receive new capabilities.

Dataverse triggers: what starts a CRM-side flow

The Dataverse connector exposes two trigger families. The first, 'When a row is added, modified or deleted', is the workhorse of CRM-side automation and the trigger you will use most often. You configure the Change type (Create, Update, or Delete), the Table name, and the Scope - User, Business Unit, Parent:Child Business Unit, or Organization - plus an optional OData filter expression on the row. A 'Run as' setting decides whether the flow executes under the flow owner, the row owner, or the modifying user, which matters for permission boundaries.

The second family, 'When an action is performed', triggers flows on Dataverse custom process actions (bound or unbound) organized into Catalogs and Categories. The action's inputs and outputs appear as dynamic content in the flow, which makes it a clean way to expose reusable business operations as automation entry points.

Two limitations are worth flagging up front. On update triggers, the 'Select columns' filter accepts scalar types only - you cannot filter on lookup fields - and the trigger does not directly support firing on changes to 1:N or N:N relationships. Also be aware that multiple updates to the same row in quick succession can fire multiple flow runs; design for idempotency rather than assuming a single run per logical change.

• →'When a row is added, modified or deleted' - configure Change type, Table, Scope, OData filter, Run as
• →'When an action is performed' - triggers on Dataverse custom process actions (bound or unbound)
• →Update-trigger filters are scalar-only (no lookups); relationship changes are not directly supported
• →Multiple row updates can fire multiple runs - design flows to be idempotent

Fin & Ops triggers and actions for ERP-side apps

For Finance, Supply Chain Management, and the other finance and operations apps, the Fin & Ops Apps connector takes a different shape. Its primary entry point for automation is the 'When a Business Event occurs' trigger, which fires on business-meaningful events such as a customer payment posted, a sales order confirmed, or a purchase order approved. Business events are configured per app and surfaced into Power Automate with a typed payload.

Because the payload arrives as JSON, the standard pattern is to follow the trigger with a 'Parse JSON' action (using a sample payload to generate the schema) so that downstream actions can reference individual fields. From there, a typical flow notifies a Teams channel, writes to Dataverse, posts to a partner webhook, or kicks off an approval.

On the action side, the Fin & Ops connector exposes data-entity operations - read and write through the OData surface that finance and operations apps publish - plus the ability to invoke executable operations. For bulk data scenarios, the connector is generally the wrong tool; data management imports, dual-write, and business events together cover most enterprise integration needs, with Power Automate handling the event-driven notification and orchestration layer.

• →'When a Business Event occurs' is the primary ERP-side trigger (e.g. Customer Payment Posted)
• →Follow the trigger with Parse JSON to expose typed fields for downstream actions
• →Action surface targets data entities (OData) plus executable operations
• →For bulk data, use data management/dual-write - Power Automate handles the event-driven layer

Dataverse actions: CRUD, relationships, files, and changesets

Once a CRM-side flow triggers, the Dataverse connector gives you a complete action surface. The row actions cover the full lifecycle: Add a row, Update a row, Delete a row, Get a row, List rows, and Upsert a row. The Upsert action is particularly useful for sync patterns where you want to create-or-update without first querying.

For related data, the Relate rows and Unrelate rows actions handle both 1:N and N:N relationships, which is how you wire up connections between accounts and contacts, opportunities and competitors, or any other relationship the data model exposes. The Perform a bound action and Perform an unbound action actions invoke Dataverse custom process actions - the same operations that can act as triggers - so you can reuse business logic from inside a flow.

Two specialized actions matter for richer scenarios. Upload a file or Download a file handles file columns and note attachments, and the Changeset action wraps a group of operations into a single transactional unit - if any one fails, all roll back. Changesets are the right tool when a flow must update several rows atomically, such as adjusting a primary contact and its related address records together.

• →Row lifecycle: Add, Update, Delete, Get, List, Upsert a row
• →Relate / Unrelate rows for 1:N and N:N relationships
• →Perform bound/unbound action to invoke reusable Dataverse custom process actions
• →Changeset wraps operations into a single transaction - all succeed or all roll back

Approval flows: human-in-the-loop across D365

Approvals are where Power Automate earns its keep for SMEs, because D365's native approval engines vary by app and rarely cross system boundaries cleanly. The 'Start and wait for an approval' action is the center of gravity.

Approval types include Approve/Reject (where you choose whether everyone must approve or the first responder wins), Custom responses (for multi-outcome decisions like Approve, Reject, or Request changes), and Sequential approvals (a chain where each stage must complete before the next). Approvals persist in Dataverse, so they survive flow restarts and are visible to approvers in multiple places: email, Microsoft Teams adaptive cards, and the Power Automate action center on web and mobile.

For SMEs, the highest-value approval patterns tie D365 events to a defined chain of sign-off: a Sales opportunity above a discount threshold routes to a sales manager and then finance; a Field Service work order over a cost ceiling routes to an operations lead; a Finance journal entry above a value routes to a controller. Because the approval lives in Dataverse, the outcome can be written back to the originating D365 app without custom code.

• →'Start and wait for an approval' is the core approval action
• →Approval types: Approve/Reject (all or first responder), Custom responses, Sequential chains
• →Approvals persist in Dataverse and surface in email, Teams adaptive cards, and the action center
• →Write the approval outcome back to the originating D365 app without custom code

Desktop flows (RPA) for legacy and UI-based tasks

Desktop flows are Power Automate's RPA capability, used to automate repetitive Windows, desktop, web, and legacy-application tasks that have no API. You build them by recording user actions or by dragging UI elements, mouse, keyboard, and image-based actions onto a canvas.

RPA runs in two modes. Attended RPA runs on a user's machine while the user is present - one attended bot is included with each Power Automate Premium license. Unattended RPA runs in the background on a machine without a user present, which is what most SMEs actually want for scheduled batch reconciliation of a legacy system; it requires Process or Hosted Process capacity allocated to a machine.

The honest SME guidance on RPA is to treat it as a last-mile tool, not a first-choice integration. Where an API, connector, or data-entity integration exists, it will be more robust than UI automation. RPA is the right answer when a legacy system genuinely has no API, when you are bridging to a desktop product like a local accounting install, or when you need to scrape and reconcile a partner portal that does not expose data any other way.

• →Automate Windows/desktop/web/legacy-app tasks via recording or drag-and-drop UI actions
• →Attended RPA: one bot per Premium license, user present
• →Unattended RPA: background, requires Process or Hosted Process capacity on a machine
• →Use RPA as a last-mile tool - prefer APIs and connectors where they exist

Licensing: D365-seeded rights vs Premium, Process, and Hosted RPA

Licensing is the part SMEs most often get wrong, because Dynamics 365 licenses seed limited Power Automate capabilities and the boundary between 'included' and 'needs a separate license' is not obvious.

What D365 licenses include: Power Automate capabilities that work in the context of the D365 app - automated, scheduled, and button flows using standard connectors, plus premium and custom connectors when used within the app context, and business process flows. The seeded capacity scales with the license: a Team Member license lands on the Low profile (around 6,000 actions per day), while Professional and Enterprise licenses land on the Medium profile (around 40,000 actions per day).

What D365 licenses do not generally include: standalone premium use outside the app context, unattended RPA without additional capacity, and full out-of-context premium-connector usage. For those, you buy standalone Power Automate licenses. Power Automate Premium is $15.00 per user/month (annual) and includes cloud flows with standard, premium, and custom connectors, one attended RPA bot, process mining, AI Builder credits (5,000/month), and Dataverse storage (250 MB database + 2 GB file per license). Power Automate Process is $150.00 per bot/month (annual) and is the license required for unattended RPA; it can also be allocated to a cloud flow for higher limits (250,000 actions per day per license, stackable). Power Automate Hosted Process is $215.00 per bot/month (annual) and adds Microsoft-hosted virtual machines so you can run unattended RPA with zero infrastructure and built-in autoscaling and load balancing.

A material change took effect April 21, 2026: Microsoft reached general availability for 'flow groups', which let you share a single Process license capacity across up to 25 cloud flows. This reduces the cost of high-volume automation where several flows do not each need dedicated capacity - previously each cloud flow needing Process capacity had to have its own Process license. If you are budgeting RPA or high-volume automation for the year ahead, model against the post-change sharing rules rather than pre-2026 pricing.

Limits and design constraints to plan around

Power Automate is not unbounded, and several limits shape how you design D365 flows. A single flow can contain up to 500 actions and 8 nesting levels. Maximum run duration is 30 days. Flows that error are suspended after 14 days, and inactive flows are turned off after 90 days - so any flow you build needs an owner who will notice and respond when it breaks.

Pagination and Apply-to-each caps range from 5,000 to 100,000 items depending on the license profile, which means bulk-processing patterns need chunking or a different tool. Combined with the Dataverse update-trigger constraint that filters are scalar-only and the absence of relationship-change triggers, the practical conclusion is that Power Automate is excellent for event-driven, human-in-the-loop, cross-system orchestration - and the wrong tool for bulk data migration, complex transformations, high-volume near-real-time sync, or anything sensitive to throttling.

For the scenarios Power Automate does not fit, the alternatives inside the D365 ecosystem are well-defined: native business rules and classic workflows for synchronous CRM logic, plugins and Dataverse custom actions for heavier CRM logic, AL extensions and the BC API for Business Central, and dual-write plus data management for finance and operations. A good partner will tell you which tool fits which problem rather than defaulting to Power Automate for everything.

• →Up to 500 actions and 8 nesting levels per flow; max run duration 30 days
• →Erroring flows suspended after 14 days; inactive flows turned off after 90 days
• →Pagination and Apply-to-each caps range from 5,000 to 100,000 items by license profile
• →For bulk/sync/high-volume needs, use native D365 business rules, plugins, AL extensions, or dual-write

Common SME automation patterns across the D365 suite

Patterns are where the architecture decisions above become concrete. Across the SMEs we work with in Canada, the UK, and the US, a handful of D365 Power Automate patterns recur because they deliver clear value and stay within the licensing and limits discussed above.

In Dynamics 365 Sales, the dominant pattern is opportunity-stage routing: when an opportunity moves to Won, post a Teams message to the delivery team, create onboarding tasks, and write a snapshot to Dataverse for revenue tracking. A second pattern is discount-threshold approval - any opportunity above a defined discount routes through a sequential approval before it can close.

In Dynamics 365 Customer Service, the common pattern is escalation handling: when a high-severity case is created or an SLA is at risk, notify a Teams channel, page an on-call agent, and create a follow-up record. In Dynamics 365 Field Service, the high-value pattern is work-order cost approval: when a work order with parts and labour exceeds a threshold, route it to operations for approval before invoicing. In Dynamics 365 Finance, the recurring pattern is payment-posted notification: when the 'Customer Payment Posted' business event fires, parse the payload, notify the collections team, and reconcile against an external portal - often with an unattended RPA bot doing the portal legwork. And in Business Central, the patterns revolve around record-event triggers and native approval integration, which we cover in detail in our Business Central Power Automate guide.