How to set up Power Automate with Dynamics 365

Two connectors look similar: "Dynamics 365" (legacy) and "Microsoft Dataverse" (modern).

Microsoft has deprecated the legacy Dynamics 365 connector. New flows should use Dataverse exclusively.

For existing flows on the legacy connector: schedule migration to Dataverse before Microsoft EOL.

Functional differences: Dataverse connector has better trigger control (specific column changes, filter scope), better security context options, and faster execution.

For solutioning: always pick Dataverse in the connector picker, even if both appear.

Add Dataverse trigger "When a row is added, modified or deleted."

Change type: pick "Added," "Modified," "Deleted," or combinations. Avoid "All" — it is the noisiest option.

Table name: pick the specific entity (e.g., Opportunity, Case, Account).

Scope: "User" (only fires for the flow owner's actions), "Business Unit," "Parent: Child Business Unit," "Organization" (fires for everyone). Default is User — change to Organization for org-wide flows.

Select columns: list specific columns to monitor for changes. Trigger only fires when these columns change, not on every row update.

Filter rows: OData query to limit which rows trigger the flow (e.g., `statuscode eq 100000001`).

Properly configured triggers cut Dataverse API calls by 80%+ vs default settings.

Default: a flow runs in the security context of the flow owner. They must have permission to every Dataverse table the flow touches.

Problem: if the owner leaves or has limited permissions, the flow fails on certain rows.

Production pattern: create an application user (service principal) with explicit security roles. Configure the flow to use this connection.

In Power Platform admin center: Environments → your env → Settings → Users + Permissions → Application users. Create a new app user.

Assign security roles: at minimum, Basic User + custom role with table-level permissions for the entities the flow touches.

In the flow, switch the Dataverse connection from "User" to the app user connection.

Lookup (1:N): use "Get a row by ID" action with the lookup field value to fetch the related record.

Polymorphic lookup (e.g., Regarding field): the related entity name is stored alongside the ID. Check the entity name before fetching.

N:N (many-to-many): use "Relate rows" / "Unrelate rows" actions to manage the relationship.

For aggregations across relationships: use "List rows" with a fetchXml query that includes joins. fetchXml is more powerful than the OData filter for complex queries.

Avoid making N+1 API calls in a loop. Batch with "List rows" + filtering when possible.

Single-row updates in a loop hit Dataverse API throttling fast. Dynamics has a per-user-per-minute API limit (~6,000 requests).

For bulk updates: use the "Perform a changeset request" action. Wrap multiple Dataverse operations into a single transactional batch.

Limits: max 1,000 operations per changeset. All operations succeed or all fail (transactional).

For inserts: use "Add row" actions inside the changeset.

For updates: use "Update a row" actions inside the changeset.

Throughput: ~10x faster than individual operations + reduces API throttle risk.

Provision a sandbox environment via Power Platform admin center.

Copy production data (or representative test data) into the sandbox.

Build and test the flow against sandbox first.

Test specific edge cases: a row where the lookup field is empty, a row owned by a user the flow does not have access to, a row that gets deleted mid-execution.

After sandbox passes, deploy to production via Solutions export/import.

Power Apps maker portal → Solutions → New solution. Name it (e.g., "Sales Automation").

Add your flow to the solution. Add any related cloud connections, environment variables, and connection references.

Export the solution from Sandbox.

Import into Production environment.

Update connection references in Production to point to production accounts/credentials.

This pattern enables version control, audit trail, and clean deployment. Individual flow builds in Production are unmanageable past 10 flows.