New command: `m365 flow set`

[mkm17]

Usage

m365 flow set [options]

Description

Sets the specified Power Automate flow

Options

Option	Description
-n, --name <name>	The name of the Power Automate flow to update.
-e, --environmentName <environmentName>	The name of the environment that contains the flow.
--definition <definition>	A JSON string containing the new flow definition to set.
--publish	Publishes the flow.
-f, --force	Don't prompt for confirmation when warnings occur.

Examples

Set a new definition for the specified flow and save it as a draft

m365 flow set --environmentName Default-d87a7535-dd31-4437-bfe1-95340acd55c5 --name 3989cb59-ce1a-4a5c-bb78-257c5c39381d --definition '{\"properties\":{\"definition\":{\"$schema\":\"https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#\",\"actions\":{\"Compose\":{\"type\":\"Compose\",\"inputs\":\"test\",\"runAfter\":{},\"metadata\":{\"operationMetadataId\":\"4f25ab1c-549e-4eaf-9980-c03020e55378\"}}},\"parameters\":{\"$authentication\":{\"defaultValue\":{},\"type\":\"SecureObject\"}},\"triggers\":{\"manual\":{\"type\":\"Request\",\"kind\":\"Button\",\"inputs\":{\"schema\":{\"type\":\"object\",\"properties\":{},\"required\":[]}},\"metadata\":{\"operationMetadataId\":\"1b2caf01-8e22-45eb-8646-77168ad14bdd\"}}},\"contentVersion\":\"1.0.0.0\",\"outputs\":{}},\"connectionReferences\":{},\"displayName\":\"Test Flow\",\"templateName\":\"\",\"environment\":{\"name\":\"Default-d87a7535-dd31-4437-bfe1-95340acd55c5\"}}}'

Set a new definition for the specified flow and publish it

m365 flow set --environmentName Default-d87a7535-dd31-4437-bfe1-95340acd55c5 --name 3989cb59-ce1a-4a5c-bb78-257c5c39381d --definition '{\"properties\":{\"definition\":{\"$schema\":\"https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#\",\"actions\":{\"Compose\":{\"type\":\"Compose\",\"inputs\":\"test\",\"runAfter\":{},\"metadata\":{\"operationMetadataId\":\"4f25ab1c-549e-4eaf-9980-c03020e55378\"}}},\"parameters\":{\"$authentication\":{\"defaultValue\":{},\"type\":\"SecureObject\"}},\"triggers\":{\"manual\":{\"type\":\"Request\",\"kind\":\"Button\",\"inputs\":{\"schema\":{\"type\":\"object\",\"properties\":{},\"required\":[]}},\"metadata\":{\"operationMetadataId\":\"1b2caf01-8e22-45eb-8646-77168ad14bdd\"}}},\"contentVersion\":\"1.0.0.0\",\"outputs\":{}},\"connectionReferences\":{},\"displayName\":\"Test Flow\",\"templateName\":\"\",\"environment\":{\"name\":\"Default-d87a7535-dd31-4437-bfe1-95340acd55c5\"}}}' --publish

Default properties

Additional Info

Hi,

I noticed that before adding or updating a flow, two calls are made: checkFlowWarnings and checkFlowErrors. I think it’s worth checking the status of warnings and errors before updating the flow. Maybe, in case of a warning, we could prompt the user for confirmation.

Let me know what you think about this command. I’d also like to add a flow add command with a similar structure.

Minimal permissions

Azure Service Management/user_impersonation delegated

[milanholemans]

Nice idea @mkm17!

A few remarks from my side.

I noticed that before adding or updating a flow, two calls are made: checkFlowWarnings and checkFlowErrors. I think it’s worth checking the status of warnings and errors before updating the flow. Maybe, in case of a warning, we could prompt the user for confirmation.

What happens when we call checkFlowErrors, and it contains an error? Does the API request fail? Or does it succeed and just return the errors in the flow? If it is the latter one, we should definitely let the user consent before updating.

For warnings, I'm not sure if it's worth letting the user consent in this case. It's a warning, and not really something critical.
Another idea would be to give this command an output when we found warnings and/or errors while updating the flow. @pnp/cli-for-microsoft-365-maintainers, what is your stance on this?

Does this command also work for flows that are part of a solution? If not, we should include it in the documentation.

[waldekmastykarz]

I suggest that we prompt for confirmation for both warnings and errors but also offer a way to suppress the prompt using the --force switch.

[mkm17]

@milanholemans @waldekmastykarz
At first glance, it looks like the request is the same in both cases (solution one and the regular one).
I also noticed that in the modern editor, there’s an option to save a flow as a draft (it seems to use the Dynamics endpoint). Do you think we should add this option as well?

From what I can see, when the checkFlowErrors endpoint returns an error but we still attempt to save, it simply returns a detailed message describing what’s wrong with the flow.
So it looks like the checkFlowErrors and checkFlowWarnings endpoints can be used only for prompting the user.

[milanholemans]

I also noticed that in the modern editor, there’s an option to save a flow as a draft (it seems to use the Dynamics endpoint). Do you think we should add this option as well?

It will probably mean that the command needs an additional permission scope. But saving it as a draft could be useful, so I'd include it.

[Adam-it]

I also noticed that in the modern editor, there’s an option to save a flow as a draft (it seems to use the Dynamics endpoint). Do you think we should add this option as well?

It will probably mean that the command needs an additional permission scope. But saving it as a draft could be useful, so I'd include it.

@milanholemans , @mkm17 do we know what scope needs to be included so we may add it to the m365 setup command. If we know we may just add it to the spec and open this issue up

[mkm17]

@Adam-it @milanholemans Hi, long time no update on this. I checked it on my side, and it looks like the Azure Service Management/user_impersonation delegated permission is required to make it work. If that is enough, I would be happy to start working on this.

[milanholemans]

Great, thanks!