[object Object]

Connection references were Microsoft’s answer to “my flows broke when I deployed to production.” They work, but only if your team treats them as first-class solution components with a real lifecycle.

What they actually are

A connection reference is a metadata pointer that lives in your solution. The actual connection (with auth tokens) lives in the target environment and is bound to the reference at import time. This decouples the flow definition from the credentials, so the same flow can authenticate as different identities in dev, test, and prod.

If you skip the reference and embed a connection directly, the flow ships hardcoded to the dev connection, which does not exist in production, and the import fails or the flow runs as the wrong identity.

Naming convention that scales

Adopt a strict naming convention before you create the second connection reference. A pattern that works:

{publisher}_{purpose}_{connector} for example contoso_invoiceapproval_outlook or contoso_dataverse_servicewriter_dataverse.

This makes connection references self-documenting in the import dialog, where someone in production must pick the right connection from a dropdown. Generic names like “MyDataverseConnection1” guarantee misbinding.

One reference per service identity

The temptation is to share one Dataverse connection reference across all flows. Resist it. Use one reference per service identity. Why:

  • Different flows have different rate-limit profiles; sharing a connection means a noisy flow throttles a critical one
  • When a service principal rotates, you want to update one bound connection, not 40 flows
  • Audit trails are clearer per-purpose

Reasonable groupings: read-only-reporting, service-writer, customer-facing-portal-flows, admin-bulk-jobs.

Service principals over user accounts

Bind connection references to service principal connections, not user accounts. Three reasons:

  1. User accounts disable when people leave; flows break silently
  2. User accounts have MFA; non-interactive flows fail consent flows after token expiry
  3. Service principals get scoped permissions and proper audit trails

In Dataverse, create an application user, assign the minimal security role, and create the connection using “Application user” auth type. The service principal becomes the executing identity for every flow that binds to it.

Lifecycle: create, bind, never re-create

The most common failure: deleting and re-creating a connection reference in dev. The new reference has a different ID, and every flow that referenced the old one is now broken. Connection references are immutable once shipped. Rename instead, or create a parallel reference and migrate flows one at a time.

Pipeline binding

In Power Platform pipelines, configure deployment settings JSON to bind references at import:

{
  "ConnectionReferences": [
    {
      "LogicalName": "contoso_dataverse_servicewriter_dataverse",
      "ConnectionId": "{prod-connection-guid}",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
    }
  ]
}

Store this file per environment; never let pipelines prompt for binding.

Audit unbound flows

Run a weekly query against Dataverse connectionreference and workflow tables to find any flow without a bound connection reference. These are time bombs.

What to do this week: audit your existing flows, assign every connection to a named connection reference, and bind them all to service principals.

[object Object]
Share