Connection references and disabled flows – what’s the connection?

Have you ever had your flows turned off when importing them through a solution? It’s been a bit of a mystery to me for a while. I had some idea about what to look at, but it’s only now that I looked closer.

Maybe you’ll find it useful, too.

First of all, every Flow can have multiple connection references. If you are not familiar with the concept yet, have a look here:

https://docs.microsoft.com/en-us/powerapps/maker/data-platform/create-connection-reference

When importing a solution with such flows, and if required connection references do not exist in the target environment yet, you’ll be presented with a dialog to set up those connection references. On the high level, I believe here is how it works:

And here is connections “configuration” dialog:

In the simple scenario where neither the connection reference nor the flows have ever been imported into the target environment yet, you’ll get everything up and running as a result.

However, there are some edge cases, it seems.

For example, imagine that there are two different developers working on this solution in the dev environment. Also, imagine that connection references have been separated into another solution, so the Flows are, still, in the main solution. And connection references are in a different one.

In my case, the idea was that connection references would be imported and configured by somebody who has required Sharepoint etc permissions in the target environment. In the end, it seems to be going against the “flow”, but I’ll explain down below.

For now, just look at how, depending on who’s importing the Flows solution (once connection references have been imported and configured), we are going to have Flows turned on or off.

Here, the flows are “on”:

And they are “off” below:

In both cases, the same solution was imported into the environment where that solution had not been imported before. However, you can see how the owner of the Flows is different, and, normally, you’ll see the name of the user who imported that solution in the “Owner” column in those views.

Here is another screenshot – notice who owns connection references:

My flows were not turned on when they were imported by a different user. Which seems to correspond to what’s mentioned in the docs (there was a link above):

It’s, probably, not so much about who owns connection references – more about whose connections are linked to the connection references?

However, there is, also, another twist to this.

What if I added all my connection references to the flows solution in the source? Let’s stay I kept connection references in the separate solution, too, and let’s say that solution has already been imported into the target.

Here is how my solution in dev would look like:

When trying to import that solution into the target environment, I’d get the same connection references configuration dialog, no matter which use account I use:

In other words, whether I have connection references imported into the target or not, I will see the dialog above when those connection references are part of my “flows” solution.

However, if they are not part of the solution, and if connection references had already been imported into the target prior to starting solution import for the flows, the dialog above will not be presented, and no dependency checks will fail. Still, whether the flows will be turned on or off depends on whether Flow owner will end up being the same as the user owning those connections.

It seems there is some inconsistency there? Although, maybe I’m still missing something.

What’s, actually, bugging me is that, it seems, in order to make those deployments work, we always need to be using the same deployment account (to make sure connections and flows are in sync) – that would work nicely with ALM, of course, but what if we wanted to do manual deployments every now and then?