Working with the Cloud Flow “ChildFlowNeverPublished” error

I came across a little brainteaser while trying to enable my Cloud Flows after importing solution to new environment for the first time. While trying to “Turn On” my flows, I received an error that they were never published. I found this odd, as I published all customizations before exporting my solution…

Error that I received:

Turn on failed. Flow client error returned with status code “BadRequest” and details “{“error”:{“code”:”ChildFlowNeverPublished”,”message”:”The workflow with id ‘{flowId}’ cannot be used as a child workflow because it has never been published. Child workflows need to be published at least once before they can be included in a published parent workflow.”}}”

Troubleshooting the problem

I started to troubleshoot the problem by reimporting new solution that I had made sure was published (multiple times), but that didn’t work. I reimported a solution with an updated minor version number (x.X.x.x), but that didn’t help either. I deleted my managed solution and imported an unmanaged one in the hope of getting the Flows to turn on by tinkering with edit-mode, publishing and copying. No luck there either, so I had to take a coffee break.

After much more investigating, I came across a blog post by Tomasz Poszytek, which mentions that Flows might have a circular reference, causing the error message that I received. In his scenario, he wanted to delete a component, while I wanted to turn my flows on, but the error message is the same. This means that I need to validate my Flows and understand what is going on.

Understanding circular reference

The circular reference problem seems to be caused by a Child Flow using another Child Flow that the Main Flow is already using. In my example below, my Main Process includes a Child Process and a separate Flow for unified Error Handling. Error Handling is only executed if an error occurs in either process, but this generates a circular reference, which is the source of our problem.

How to fix circular reference

Fixing the problem means redoing our Flow architecture. In this example, we will remove the reference from the Child Process to Error Handling. Instead, when the Child Process encounters an error, it will notify the Main Process. Essentially, the action in the Main Process that waits for the response will receive the error status. This will then trigger the Error Scope in the Main Process, which calls the Error Handling Child Flow.

Above is a very simplified example of the problem and how to fix it. In reality, my and your processes might be complex, and breaking down Child Flows will take a lot of work. I had to move some processes from the Child Flows back to Main Flow in order to break circular references.

One extremely annoying part of this error is that it is very hard to notice while developing. There was no indication in the Development environment because once you get your Child Flow on, it does not care about circular references anymore. This means that there is a possibility of having a Child Flow turned on in your environment and importing a solution update that contains circular reference, and everything works without issues.

I hope this post speeds up your troubleshooting and helps you understand what a circular reference means and how to fix it!