[power-automate][Bug] update_flow/edit_flow cannot save any solution-aware flow using connection references — read/write schema mismatch ending in HTTP 500

[CraigWhite81]

Plugin

power-automate

Plugin Version

2.3.1

Skill / Command

N/A — flowagent MCP tools (get_flow, edit_flow, update_flow)

Bug Description

The plugin can read solution-aware flows but cannot write them. get_flow returns action inputs in the runtime shape, while the Dataverse save endpoint requires the design shape. A verbatim read-modify-write round-trip is therefore always rejected, and no combination the plugin can express satisfies the validator.

get_flow returns:

"host": {
  "apiId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps",
  "connectionName": "shared_commondataserviceforapps",
  "operationId": "GetItem"
},
"authentication": "@parameters('$authentication')"

The save endpoint requires:

"host": {
  "apiId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps",
  "connectionReferenceName": "<key>",
  "operationId": "GetItem"
}

...with no authentication property at all.

This blocks every definition edit, however small — the failing operation is the save itself, not any particular change. The affected flow is an ordinary unmanaged solution flow with five connection references (Dataverse, SharePoint, OneDrive, Office 365 Outlook, Office 365 Users), which should be a common case.

Steps to Reproduce

1. Create a solution-aware cloud flow that uses connection references ("source": "Embedded") in an unmanaged Dataverse solution.
2. Call get_flow to retrieve the definition.
3. Attempt to change any single property — e.g. edit_flow with one set op on a Compose action's inputs.
4. The save is rejected. Correcting each reported error in turn leads to the next error, ending in an unhandled server-side exception.

Expected Behavior

A read-modify-write round-trip should succeed. Either the write path should accept the same shape the read path emits, or the plugin should convert between the runtime and design shapes internally — including emitting a matching connectionReferences map alongside the definition.

Actual Behavior

Five distinct failures, each surfaced only after fixing the previous one:

#	Attempt	Result
1	Send back exactly what get_flow returned	should not have the property 'authentication'
2	Strip authentication	Property 'host.connectionReferenceName' is missing
3	Add connectionReferenceName	The API connection reference could not be found — edit_flow patches only the definition and never sends a connectionReferences map
4	update_flow + solution-export-shape refs	InvalidRequestContent, cannot deserialise runtimeSource
5	update_flow + verbatim read-shape refs + connectionReferenceName hosts	HTTP 500 NullReferenceException

Step 5 is an unhandled server-side exception and should not be reachable from plugin input regardless of whether the payload is correct.

Note: all failed saves were atomic — the flow was verified byte-identical afterwards — but lastModifiedTime is still bumped by a rejected save, so it cannot be used to detect whether a write landed.

Relevant Logs / Screenshots

Flow ID, environment ID, connection reference logical names and action names redacted.

1. XrmApiRequestFailed / InvalidOpenApiFlow

Flow save failed with code 'WorkflowRunActionInputsInvalidProperty' and message
'The 'inputs' of workflow run action '<ACTION>' of type 'OpenApiConnection'
should not have the property 'authentication'.'

2. XrmApiRequestFailed / InvalidOpenApiFlow

Flow save failed with code 'WorkflowRunActionInputsMissingProperty' and message
'The 'inputs' of workflow run action '<ACTION>' of type 'OpenApiConnection'
is not valid. Property 'host.connectionReferenceName' is missing.'

3. XrmApiRequestFailed / InvalidOpenApiFlow

Flow save failed with code 'WorkflowRunActionInputsInvalidProperty' and message
'The API connection reference 'shared_commondataserviceforapps' could not be
found for the operation '<ACTION>'.'

4. InvalidRequestContent

The request content was invalid and could not be deserialized:
'Invalid JSON at path
'properties.connectionReferences.shared_commondataserviceforapps.runtimeSource'.'

5. XrmApiServerError (HTTP 500)

Flow server error returned with status code "InternalServerError" and details
"{"error":{"code":"InternalServerError","message":"Http request failed with
unhandled exception of type 'NullReferenceException' and message: 'Object
reference not set to an instance of an object.'."}}"
Code: 0x80097376

Environment

• OS: Windows 11 Home 10.0.26200
• Claude Code: 2.1.220
• PAC CLI: 2.9.3+ga17df1d
• Plugin: power-automate 2.3.1

The failure is server-side in the Flow/Dataverse save API, so the local environment is likely not a factor.

---

🤖 This issue was created using the /report-issue skill.

[brockwaters]

Confirming this on plugin version 2.3.1, independently, with two additional data points that narrow the root cause further:

1. It's not staleness or propagation delay. I tested against a connection reference that was months old and actively used by other flows in the same solution (not newly created). Referencing it by connectionReferenceName in a new action on a different flow in that same solution still fails with the identical error:

Flow save failed with code 'WorkflowRunActionInputsInvalidProperty' and message
'The API connection reference '<name>' could not be found for the operation '<ACTION>'.'

This rules out the reference itself being incomplete, unresolved, or too new to have propagated — it's demonstrably valid and in-use elsewhere.

2. It's not about action complexity or the specific connector operation. I isolated this to the smallest possible repro: a single new no-op OpenApiConnection action with an empty parameters: {} object, calling a trivial read-only operation, referencing the same known-good connectionReferenceName. Same error, verbatim.

3. Tried both write paths described in the original report — direct connectionReferenceName on the host, and connectionName + a matching connectionRefs entry (which correctly auto-resolved to the existing reference by name, confirmed via a preview_update diff) — both fail identically at save.

One more variable worth checking, in case it helps narrow this down: my target flow had zero pre-existing connector actions (only built-in Compose/Response/child-flow-call types) before I tried adding the first one. If anyone reproducing this has a flow that already has at least one working connector action and is just adding a second, it'd be useful to know whether that case behaves differently — it would help distinguish "this API can never add a connection reference to any solution flow" from "this API can never add the first connection reference to a flow that didn't have one before."

Also created via a scenario the original report doesn't mention: the target flow was originally provisioned by pushing a JSON definition directly (via create_flow-equivalent, provisioningMethod: FromDefinition) rather than built from scratch in the designer — unconfirmed whether that's relevant, but flagging it as a variable in case someone can test a designer-originated flow for comparison.

[CraigWhite81]

Was a simple "fix" for me in the end. My error appears to be the plugin trying to use the Power Platform API and failing. I asked Claude Code (in my instance) to try with the Dataverse API and everything seemed to work fine, even if the flow has connection refs, it's in a solution etc.

Not sure if that helps the team review and fix but sharing my findings since I logged the original bug

[radioblazer]

Fixed in v3.0.1 — resolved in PR #393, merged 2026-08-12.

Please update to v3.0.1 and let us know if you're still seeing this.