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.
We are now working on this and will release it in the next couple of months.
Thanks @Apruzz. Very kind of you to post this helpful tip. I will have to try your technique. Since Flow is targeted at non coders, it should have a simple action call "Launch Other Flow" or "Terminate other flow" ultimately.
I know, but you'll see it's almost that simple.
Thanks to those above for the pointer to the "When an http request is received" action approach. Far less painful than I expected, and saved by bacon.
There's an issue whereby the "Apply to each loop" concurrency / parallelism settings doesn't work with "Send an Email with options" actions inside the loop i.e. it ignores the parallel consurrent setting and does it sequential. Which is no use for an approvals requirement. Using "When an http request is received" and refacgoring the Flow into Flows sorted that.
Didn't stop my customer asking why a product a decade in the making and a mid-life re-write (SP workflow -> Flow) still can't do a loop with parallelelism / concurrency with an approvals email inside it out-of-the-box.
But hey-ho, it was ever thus where Redmond is concerned.
I haven't encountered the bug you mentioned, but I'm curious about it. When you say "Send e-mail with options" won't run concurrently in a loop, why is that such an issue? Isn't it just a few seconds' delay for the loop to run sequentially? Do you mean that the second iteration doesn't run until someone has selected an option in the e-mail from the first iteration? I've managed to send e-mails with options all at once - not perfectly simultaneously, but at roughtly the same time from inside a loop. Can you explain the issue further?
When I put a "Send email with options" action inside a "Apply to each" loop (each iteration has an "approver" from an array, this is a parallel approval workflow) with the loop concurrency enabled, the emails are only sent sequentially i.e. the n+1th is only sent when someone responds to the nth. The approval I wanted was to be parallel i.e. everyone gets the email immediately and can respond in theor own time and in any order.
This is the issue exactly ...
You can see my "Redmond Rant" comment at the end there.
Then I found this one ...
MS purport to have fixed it in that one, but it ain't. Not always. Maybe sometimes. It was working, then it didn't.
So you can see my super-charged "Redmond Rant" comment on the end there too.
Then I found this thread, and tried out the "When an http request is received" action approach expecting hell on earth, but it was graceful and uncomplicated.
Hmm. I just tried and was not able to replicate your issue with "e-mail with options" action. I was able to send out a bunch of e-mails all at once, as long as I set apply to each to run in parallel. Guess you do max out at 50 simultaneous e-mails, but I can't imagine a scenario where more would be required (or you couldn't find a way to split the process into multiple loops).
Anyway, glad my post helped you solve your issue.
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.
This feature would be really great!