Ok, so some time ago, I have committed a post about an issue which occurs, when one tries to turn on a flow deployed to another environment, that has a circular reference with other flows.

The post can be found here, and it describes a flows’ architecture as in the picture below:

I wrote back then that a solution to that is to create a controller child flow, which is called by the stage flows, and which then call the state machine flow:

However, it turns out (which was kinda obvious), that this setup does also create a circular loop:

1. State machine calls stage flow
2. Stage flow calls controller
3. Controller calls state machine

But, when it comes to turning the flows “on” after the first deployment, this will never work, because still:

1. To turn on state machine flow, the stage flow must be turned on first…
2. To turn on stage flow, the state change flow must be turned on first…
3. To turn on state change flow, the state machine flow must be turned on first…

And so this still makes it impossible to make the whole solution running, ending with the following error, when trying to turn on whichever flow from the loop:

Turn on failed. Flow client error returned with status code "BadRequest" and details "{"error":{"code":"ChildFlowNeverPublished","message":"The workflow with id 'flow-guid' 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."}}".

The solutions?

I came up with several ideas, some of them worse than others 😉

1. Break the circular loop, by replacing one trigger with Web request trigger, and calling child flow with HTTP action.
2. Edit child flows on production, remove the reference, publish, add reference – this one is terrible, as it may create unmanaged layer.
3. Break the circular loop by triggering child flows using a supporting SharePoint list or Dataverse table – you know, when a new item is created. Nightmare!

Things get even worse, if an environment where the managed solution is deployed, has “unmanaged changes” disabled by administrator – in such a case, there is not really a way to edit the flow and break the loop.

And even though Microsoft promised to fix this inconvenience, it is still present and messes up with other developers’ cool solutions too.

The really working solution!

This is pretty simple.

1. First, remove the existing solution from target environment. No, you won’t be able to turn it on anytime soon 🙂
2. Break the loop in your dev environment. Remove any “Run a child flow” action, in whichever flow in the loop, so that the circular reference is broken.
   
3. Publish the flow.
4. Make a deployment again.
5. Turn on the flows – starting from the one, that has the reference broken. Obviously, if they are not already turned on (you know, in that decent way ;))
6. Restore the circular reference in the flow from point no. 2.
7. Make another deploy.

And all works just fine! I hope this will help you too. Let me know in comments how it went.