In recent months I’ve been very active within the Microsoft Flow community and in general Flow has very much matured as a product over the last year. As with all Microsoft Products Microsoft Flow has it’s uservoice site where you can submit your ideas for the product.
With about 6000 ideas, it is difficult to see if someone else has had the same ideas. But at least you can see what Microsoft is working on by listing the 17 planned ideas and the 18 under review ideas. These ideas have all been upvoted by people that are part of the Flow community. Did you know that when you upvote an idea that you automatically will receive an email when there is any progress on the delivery of that idea?
But actually, I find it more important to get many of the other ideas into the planned/review stage. Below is my top 10 of items already on the uservocie site that could do with some more votes.
The flow interface is great as you can drag ‘n drop actions from one place to another. However copying the actions from one place to another is not possible. Imagine if you have 3 almost identical emails that needs to be sent out during different stages of your flow. Then all you can do is create a new action 3 times and update each of the settings in the actions. Ok, you can use Select-All/Copy/Paste ( Ctrl-A, Ctrl-C, Ctrl-V), but still replicating all the fields is painful
The management screen for completed flows can do with some improvements. One of these improvements would be the option to resubmit failed multiple workflows
A while back Maarten Eekels submitted a uservoice for this.
While looking at the run history, it would be helpful if we could see the trigger details of a flow. One of the obvious ideas is SharePoint list items/document that triggered a flow. I found a Uservoice for this, but this should be a bit more generic and show any trigger details. So that you can identify which flow is related to which data. Maybe we should even get an option to search through the run history.
It would be great if we could have multiple triggers on a Flow. So imagine if you have 2 document libraries in SharePoint and you could have one flow triggering whenever a document is uploaded to either library.
Or how about a flow can be trigger manually or when a list item is created. There might be many different options. That will become available with multiple triggers in a single Flow. Of course you could create multiple flows that all start a single secondary flow. but that would become unmanageable fairly rapidly.
It should be possible to just trigger a flow when a specific field is changed in a SharePoint list. I’m seeing a lot of flows repeatedly triggered when all the flow does is exit out on initial condition that checks a value on the triggering item.
When initializing variables you end up with many actions cluttering the designer interface. Unfortunately it isn’t possible to put these actions in a scope action. The only thing I found that helps a little bit is creating the actions as parallel actions
This way still a lot of space is taken but wider flows are easier to handle than tall flows.
When developing flows it can be helpful to disable some steps. This is currently not possible putting conditions like true=false around unwanted actions isn’t really the right option.
When a flow is triggered by the modification of a SharePoint item it would help if you could also get to the previous values of the fields. This way you could add conditions in your flow that depend on specific changes of you SharePoint data.
Have you been using the REST API instead of the create item action in Power…