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.
Nintex has offer that powerful feature for years. It allows to create smaller modular flows that are easy to restarts, versus having a very long and complex flow. Please allow parameters being passed when launching a sub flow.
It would be helpful to be able to have flows operate more in a modular fashion. I repeat a lot of actions when a flow is very similar. Plus, you cannot copy from one to another so it makes repeating actions to other flows very time consuming and error prone. Save As only accounts for some.
You can do this, and it's not as hard as you think.
Whatever Flow you want to launch from another Flow, you have to start with an HTTP trigger. Once you save your Flow, you'll have be able to see the Url for the HTTP endpoint that can trigger your Flow. Copy it.
Go to the Flow you want to use to trigger your new Flow. Add an HTTP request/response action. Paste in the Url. Use "Post" method.
The most intimidating part is the JSON schema. It can be extremely simple, though. Eg:
"parameter_name_of_your_choice": your dynamic content
That's all you need in your triggering Flow. Notice that the line in between the brackets is "indented" with a single space. In the Flow being triggered, you need to define a schema. There's an option to generate based on a sample payload. All you have to do is type an example, like the one above (or yours can be more complicated if, say, you want to pass in 10 parameters), and let Flow generate the schema for you. Each of those parameters will be available in dynamic content after that, so you can do whatever you want with them from there.
It would be helpful if we can create a Generic flow (sub flow with common functionality) and integrate this to the main Flow under same functionality as child actions whereever it is required. This is similar like creating a common function and using it in multiples places of the code where common functionality is required in normal C# / Java / C++ programming.
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.