Flows with CDS (Current Environment) are Disabled during Import Azure DevOps/Power Platform Build Tools

[jzia93]

Microsoft offers the Common Data Service (Current Environment) as a connector in Power Automate that enables transfer of solution aware flows in an 'enabled' state - no further authorisation is required and the flows can be moved across environments without re-enabling manually. 

Azure DevOps offers the Power Platform Build Tools to automate deployments between environments as part of an enterprise-grade ALM deployment for Flows, but this is negated when the flows need to be enabled manually during import.

• There is a setting in Import Solution to 'enable workflows during import' which doesn't do anything.
• Enabled workflows cannot be updated as they are unmanaged customisations.
• 'Overwrite Unmanaged Customisations' updates the flows, but resets them to the 'disabled' state, even if the only connections required are Common Data Service (Current Environment)

Please Address this issue - it becomes very difficult to build any realistic DevOps with Power Automate when we need to enable flows manually every time. A few other points:

• PowerShell scripts do not support service principles at this time, so that is not a workaround
• PowerShell scripts do not work with MFA-enabled accounts, so tenants with MFA cannot build scripts to enable flows without manually signing in each time.
• Power Automate Management Connector does not work well with Solution-aware flows at this time

[v-alzhan-msft · Accepted solution]

Hi @jzia93 ,

Thank you for your sharing.

Best Regards,

Alice

Community Support Team _ Alice Zhang
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[mbk]

Hi 

Why is this problem marked as solved?

- I don't see any solution - not even a workaround?

I would love to hear from Microsoft what the status is on solving this problem, and what we are supposed to do in the mean time?

- this problem has been around for several months now. It is hart to gain trust in a platform (the Power Platform), when something as critical as this is still not working. 

(I have this problem too - whenever I move my solution from DEV to TEST, or from TEST to PROD I have to manually correct my flows to solve the problem that they are not imported correctly together with the rest of my solution. This is very annoying and makes the hole deployment process very error-prone - the exact reason why you would want to use an ALM solution in the first place, but this problem defeats its purpose completely)

Kind regards

Michael

[MaartendK]

Hi,

Eventually, I seem to have found two workarounds for this issue.

Issue: Cloud Flows part of my D365 solution are disabled each time the solution is deployed by my DevOps Release pipeline.

Workaround 1: if applicable, use a Service Connection based on Username and Password in the pipeline import task instead of using a Service Connection based on Service Principle. Disadvantage is of course, that after changing the password, your pipeline stops working and that it's not possible when using MFA on your useraccount.

Workaround 2: create a Flow (not part of your D365 solution) in the target environment. The Flow can use a scheduled trigger, followed by a List Flows as Admin action. Then based on criteria like displayname of the Flow, the Flow can be turned On by a Turn On Flow action, see screenshot underneath.

Best regards,

Maarten