Answered

Error 0x80060888 (BadRequest) using Env Variables in "Run a Child Flow"

(0) Share

Report

Posted on by wreta

Hi everyone,
I am facing a persistent and blocking error when trying to dynamically call a Child Flow using Environment Variables for the Flow ID.

The issue is very specific: when I select the child flow directly from the dropdown menu in the "Run a Child Flow" action, it works perfectly. However, as soon as I replace the hardcoded flow selection with an Environment Variable (storing the flow's GUID), the Parent Flow fails immediately with a syntax error in the cache request.

Error Message:

Request to XRM API failed with server error: 'Message: Flow server error returned with status code "InternalServerError" and details "{"error":{"code":"InternalServerError","message":"Http request failed with unhandled exception of type 'ProcessSimpleDataException' and message: 'Error en la solicitud de caché para el flujo de trabajo con id... se devolvió el código de estado \"BadRequest\" y el mensaje \"Message: Bad Request - Error in query syntax. Code: 0x80060888\"...

Exhaustive Troubleshooting Performed:

Trigger Change: Initially, the child flow used the standard "Manually trigger a flow". To troubleshoot the BadRequest error, we migrated the child flow to an "HTTP Request" trigger with an immediate response. Despite this change, the error in the Parent Flow (when using the Environment Variable) remains exactly the same.
GUID Validation: I have double-checked that the Environment Variable contains the correct and current GUID of the child flow.
Intermediate Variable: I tried initializing a local string variable with the Environment Variable's value before the call, but the error persists.
Comparison: Environment Variables are working perfectly within the same solution for SharePoint sites, Lists, and Excel connectors. The failure is exclusive to the "Run a Child Flow" action.

Conclusion:

This seems to be an internal bug in how the Power Automate engine validates the cache when resolving a GUID from a variable before execution (ProcessSimpleDataException). This prevents us from following ALM best practices, as it forces us to manually edit flows when moving solutions between environments (Dev/Test/Prod).

Has anyone found a workaround for this, or is Microsoft aware of this bug in the modern designer?

Categories:

Building flows

Using flows

I have the same question (0)

All responses (2)

Answers (1)

Sort by

Verified answer

Sunil Kumar Pashikanti 1,668 Moderator on at

Like (1)

Report
Copy link

Link copied!

Hi @wreta,

Yes, this is a known limitation. The “Run a child flow” action does not support dynamic Flow IDs (including Environment Variables). The designer validates the child flow at save time, and when the ID comes from a variable it fails with BadRequest / 0x80060888.

References / proof

Power Platform Community confirms dynamic child selection isn’t supported:
https://community.powerplatform.com/forums/thread/details/?threadid=392e53cb-18b8-ef11-b8e8-6045bdec8eeb

Microsoft Docs – Child flows (design-time validation & constraints):

https://learn.microsoft.com/power-automate/create-child-flows

Workaround

Use HTTP-triggered child flows and call them via HTTP action (store URLs in env vars/config), or keep static child bindings per environment.

✅ If this answer helped resolve your issue, please mark it as Accepted so it can help others with the same problem.
👍 Feel free to Like the post if you found it useful.

Was this reply helpful? Yes No
wreta 9 on at

Like (1)

Report
Copy link

Link copied!
Hi @Sunil Kumar Pashikanti,

First of all, thank you very much for your response and for providing those references.

Your explanation confirms our suspicions: the Power Automate engine is currently not designed to handle Environment Variables within the "Run a Child Flow" action due to the design-time validation requirement. As you mentioned, since the flow ID is not static, the designer cannot validate the schema, resulting in the BadRequest / 0x80060888 error.

I wanted to share our final outcome to help others who might be navigating this same path:

1. The HTTP Trigger Test & Authentication:
We explored changing the Child Flow trigger to "When an HTTP request is received". However, we quickly encountered a major hurdle: Authentication. Unlike the native "Run a Child Flow" action, which manages permissions within the solution context, the HTTP action requires manual OAuth/Azure AD configuration. This adds a layer of complexity and potential security overhead that we wanted to avoid.

2. Our Final Implementation (The "Static Binding" approach):
To ensure stability for our UAT (User Acceptance Testing) phase, we decided to stick with the Static Binding path:

After importing the solution into the Target Environment (Test), we manually edited the Parent Flow once.

We removed the Environment Variable and manually selected the local Child Flow from the dropdown menu.

We saved and turned it on.

Conclusion: While it’s not the "fully automated" deployment we hoped for, this manual re-binding takes only 10 seconds and ensures a 100% stable, secure, and functional flow without the need for Premium HTTP workarounds or complex authentication setups.

Thanks again for the help!

Was this reply helpful? Yes No