I am wondering if PowerAutomate flows can really be part of CI/CD when there are non-CDS connections?
There seem to be a few problems here:
- Once deployed, the flow is turned off, and all non-CDS connections have to be re-wired in order to turn it on. That’s a manual step
- While re-wiring the connections, we’ll be creating an unmanaged customization for a managed flow (assuming all deployments are using managed solutions
The first item undermines the idea of fully automated deployments.
The second item means, that we might not be able to deploy flow updates through a managed solution unless we remove unmanaged customizations (or the flow) first.
Here is how the flow looks like once it’s been deployed through a managed solution:
It’s off, since, in addition to the CDS (current environment) connector used for the trigger and one of the actions, there is an Office 365 Outlook connector in that flow, and the connection needs to be re-wired for that one:
If I tried turning the Flow on in the target environment, I’d get this error:
So… Have to edit the flow, and, to start with, have to sign into that Outlook connection:
Surprisingly, I can’t. Well, I can’t from the managed solution. Which is not that surprisingly come to think of it, but still…
From the default solution, I can do it:
The CDS connection re-wires automatically once I click “continue”(even though, presumably, it does not need to. At least does not need to be re-wired when there are other connections in the Flow), and, now, I can activate the Flow.
So far, it seems, I’ve just managed to demonstrate how automated deployment becomes broken.
But what about those unmanaged customizations?
Well, by re-wiring the connections, I got an unmanaged customizations layer for the Flow:
What if I the Flow were updated in the source environment?
For example, let’s change the email body. It used to be like this in the first version:
Let’s make it slightly different:
Once deployed in the target environment, the Flow is on. But that email action is still using original text:
Now, when importing the solution, we have a few options. What if I used the one which is not recommended?
This will take care of the updates, but the flow will be turned off. Because, I’m assuming, those connections were originally fixed in the unmanaged layer, and now at least some of those changes have been rolled back. Which means the connections have to be re-wired again before I can turn on the flow.
From the CI/CD perspective, this all seems to be a little cumbersome, so I am wondering how is everybody else doing CI/CD with flows?
Good question. I am currently deleting the unmanaged layer before deploying an update to the flow. This works for me.
I have not tried the ‘not recommended’ overwrite customizations way of importing solution.
The other issue that I believe needs to be resolved is that Flows (and Canvas Apps) are not supported when performing instance operations such as backup, restore and copy, as documented here.
“Database operations such as backup, restore, and copy are not supported for canvas apps and flows. These operations can corrupt canvas apps and flows.”
We found this out the hard way when we copied an instance (this is not mentioned in the copy and instance doco) and found situations where performing the action in the copied instance caused the Flow to fire in both the source and destination instances. Presumably it copies the webhook that fires the Flow, but leaves the connected instance still pointing at the source instance.
The idea that using these tools means you can’t backup your instances anymore is obviously untenable.