This feature would be fantastic for creating a modular environment. The passing of parameters between flows and essentially creating the ability to make functions would make flows an irreplacable asset to my work.
This item was part of the October 2019 release : https://flow.microsoft.com/blog/october-updates-for-microsoft-flow/
Mmm, others have also reported it works ok, and mine did work for a while too. Then it just stopped - immediately after I handed it over to my customer for UAT! Hence ranties unsued.
Anyway, the http web services approach I'd always mentally confined to using with Azure Logic Apps, Functions, etc.. Now that it seems reasonably usable and robust in Flow in opens up new architectures for doing this sort of thing in Flow, and I wouldn't have come to it without the issue and your comments.
So all's well that ends well.
As covered in the comments this is currenly supported via HTTP request/response. However, we are planning on adding a more native way of integrating flows together.
Why couldnt you just use a table in SQL or SharePoint or Basically any table ?
Flow Number 1 runs and updates [Table] with # of flow that should run next Ex. #2
Flow Number 2 triggers becouse the table was modified and #2 was entered in the field
Basically , use a table where you have all your flows triggering when the table gets modified. Within Each flow , update the [Table] with whatever flow number you want to run. Of course , each flow would need to getitems and only run if the number in the field equals whatever number the current flow is.
This is not as efficient as being able to call a flow directly in a flow, but it does allow modular flow development and reusable flows.
There are ways to start a flow from Powerapps, passing parameters.
It's a shame we don't have the same for starting flows from within flows.
This would make it really easy to start using flows as "functions" that can be reused.
Currently, I find myself reproducing parts of flows in several "copies" of the flow.
A (simple) example?
Suppose I create a logging SP list for seeing all the changes some of my important flows actually perform (this could be for debugging or for other reasons). I have to reproduce all the parameters of this "create item" step time and again, while I would love to just abstract it away in a flow called log_entry that I just pass some parameters to (the actual info to log).
Obviously this has the added advantage of better maintainability (if there is an error in my logic or if I want to change the way it works, I just have to make the change in one place).
Agree that this would be useful feature.
The way I have overcome this is to use a sharepoint list to be the interface, in that I write the data that I want to pass to the new flow into a list and then have the Child flow trigger on a new row to the list . The Child flow reads in the data from the list and has that as its starting point, deleting the row when it has finished.
I also really need this feature...
Here is my case : I have a flow that can be triggered whether from a list item OR from a small PowerApps app. As of now, I duplicated the flow since the triggers are different.
I would prefer to have one "BASE" flow and 2 small flows calling the BASE flow: one triggered from a selected list item and another one triggered from PowerApps. This way, when I need to update the way the flow behaves, I just change my BASE flow.
Hope this will come soon... 🙂
I worked out a way to do this. Create an interface list that contains the parameters you want to pass between the flows. The parent flows write to the interface list being triggered with by powerapps or something else.
Your child flow which has the common code is triggered on a new row being added to the interface list.
Last thing the child flow does is to remove the entry in the interface list to tidy up.
It works quite well and you have the arguments stored in the interface list t9 help with debugging
Thanks for your post-back... In fact, I found an easier solution in another similar idea (https://powerusers.microsoft.com/t5/Flow-Ideas/Flows-trigger-other-flows/idi-p/29002).
The solution is here:
I tested it and it works fine... 🙂
I do agree that your solution is a workaround that creates the effect I'm looking for.
Yet: that's exactly what it is: a workaround!
That notwithstanding: thank you for your contribution. Maybe some people will find your suggestion and actually be able to use it.
@Jambo1 : totally agreed ! 🙂