Challenge
Solution deployment may not be as simple as it looks like in the beginning. During one of our test deployments, all processes were turned off automatically. While this is pretty normal situation after deployment, this time trying to turn them on resulted in the message “ChildFlowNeverPublished”. Interesting, considering the fact, that there was never before a need to manually publish Power Automate solutions before. Even more interesting, considering publishing solution didn’t help. Neither did publishing flows one by one. So, what happened? And why didn’t it happen on the development environment?
Solution
After looking for answers inside my flows, I checked the web for answers. After brief research, it looks like Tomek Poszytek also faced the same issue and for both of us, the reason for the exception was the same – circular references in the solution.
See more: https://poszytek.eu/en/microsoft-en/office-365-en/powerautomate-en/childflowneverpublished/
However, the design of my automation was a bit different than Tomek’s:
Now, according to my colleague’s article, adding a proxy should resolve the issue. Then, the design would look like this:
The above solution seems not to remove the core problem at first glance. The proxy flow is not breaking the circular reference in this scenario – it simply adds one more step to it. However, none of the flows refers directly to others, which might be the clue here. Unfortunately, the above implementation didn’t resolve the issue after deployment to the test environment – the ChildFlowNeverPublished exception still occurred.
So, what to do with it? Circular reference seems to be the problem and it should be broken to prevent the error from appearing. How can it be broken then? After brainstorming the issue, it occurred to me that on the development system, the whole processing was never turned off in the first place. After turning it on, everything worked perfectly. So, what needs to be done is breaking the circular reference only to turn on the flows. Afterwards, this change could be revoked. And it seems that Power Automate has the tool to do it – the unmanaged layer.
To get it done, I edited a Processing flow’s “Run a Child Flow” to reference a dummy flow and saved it. One point to me – saved correctly. Then turned it on – second point, the flow turned on without an exception. The design at this point looked like this:
The circular reference is temporarily broken, so I tried with other flows. All of them turned on without an error. Finally, it’s time to get the changes revoked. With all flows turned on, I deleted the unmanaged layer on the processing flow and voila! No exceptions. Further testing of the flow proved it works as intended. Case solved.
Summary
Deploying a solution with child flows may encounter challenges such as the ChildFlowNeverPublished error. The key to solving this problem is understanding that it may be caused by circular references in the solution. Temporarily breaking these references by editing flows and using the unmanaged layer can help turn on the flows without exceptions. After turning on all flows, the changes can be revoked, restoring the original structure of the solution.
Similar cases have been described by Tomek Poszytek on his blog. His solution involved adding a proxy flow to break the circular references, which, however, didn’t work in my case. Each deployment may have its own unique challenges, so it’s important to be flexible and creative in approaching problem-solving.
